Messages in this thread | | | Date | Wed, 11 Oct 2006 11:46:49 +0200 | From | "Michael S. Tsirkin" <> | Subject | Re: Dropping NETIF_F_SG since no checksum feature. |
| |
Quoting r. David Miller <davem@davemloft.net>: > Subject: Re: Dropping NETIF_F_SG since no checksum feature. > > From: "Michael S. Tsirkin" <mst@mellanox.co.il> > Date: Wed, 11 Oct 2006 11:05:04 +0200 > > > So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM, > > data will be copied over rather than sent directly. > > So why does dev.c have to force set NETIF_F_SG to off then? > > Because it's more efficient to copy into a linear destination > buffer of an SKB than page sub-chunks when doing checksum+copy. >
Thanks for the explanation. Obviously its true as long as you can allocate the skb that big. I think you won't realistically be able to get 64K in a linear SKB on a busy system, though, is not that right?
OTOH, having large MTU (e.g. 64K) helps performance a lot since it reduces receive side processing overhead.
So, if I understand what you are saying correctly, things do work correctly (just slower for small skb) if NETIF_F_SG is set bug clear, it seems that all we need to do is drop the following in dev.c:
/* Fix illegal SG+CSUM combinations. */ if ((dev->features & NETIF_F_SG) && !(dev->features & NETIF_F_ALL_CSUM)) { printk(KERN_NOTICE "%s: Dropping NETIF_F_SG since no checksum feature.\n", dev->name); dev->features &= ~NETIF_F_SG; }
is that right?
-- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |