On Wed, May 21, 2014 at 8:31 AM, Simon Horman [off-list ref] wrote:
On Tue, May 20, 2014 at 07:30:38PM -0700, Jesse Gross wrote:
quoted
On Thu, May 15, 2014 at 4:07 PM, Simon Horman [off-list ref] wrote:
quoted
diff --git a/datapath/linux/compat/include/linux/netdevice.h b/datapath/linux/compat/include/linux/netdevice.h
index d726390..0381002 100644
--- a/datapath/linux/compat/include/linux/netdevice.h
+++ b/datapath/linux/compat/include/linux/netdevice.h
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
#define netif_skb_features rpl_netif_skb_features
netdev_features_t rpl_netif_skb_features(struct sk_buff *skb);
Currently this function doesn't look at mpls_features. Should it for
things other than TSO?
It seems to me that rpl_netif_skb_features is only used by
rpl_dev_queue_xmit().
If that is the case then I don't think it is necessary to examine
mpls_features, which was introduced in v3.11, as rpl_dev_queue_xmit()
only exists for older kernel versions.
Sorry, I actually meant for upstream. I agree that the compatibility
code reflects current kernels as written.
It seems like the checks in dev_hard_start_xmit() won't take
mpls_features (or the presence of MPLS) into account when deciding
whether to emulate the offload or pass the skb directly to the NIC. In
the GSO code itself, we look at mpls_features but if we never get
there then it will be too late.