Re: [PATCH net-next 1/2] net: Header length compution function

[David Miller <davem@davemloft.net>]

From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 30 Jul 2014 07:26:33 -0700

> It wasn't that I don't trust the core function.  We already had some of
> our own code floating around for the out-of-tree LRO and so I simply
> made use of that as it allowed for code reuse in our driver.

It would be nice if this code were converted to use the generic
infrastructure, at some point at least.

> I almost wonder if it wouldn't be worth while to move data_len and len
> closer to the end of the sk_buff and perhaps create a structure within
> the structure so that you could partition off all of the bits that we
> don't need for these kind of simple operations.

That is something we can certainly look into in the long term.

But it's also not all that desirable to try to extricate the
non-linear handling.  It took us a long time to get all the code to
handle non-linear SKBs :-)

And in that case you have the issue of the fragmenting state being
separate in the skb_shared_info.

Anyways, a discussion for a different thread I think.

I don't think my proposed patch is a bad trade off.  Where we have the
__skb_header_pointer() thing that takes preloaded pointers and header
length values.  It adds only one test which frankly should never
trigger and can be moved down into skb_copy_bits() or similar.