Re: [PATCH net-next 1/2] net: Header length compution function
From: David Miller <davem@davemloft.net>
Date: 2014-07-31 01:39:08
From: Alexander Duyck <redacted> 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.