On Wed, Mar 5, 2014 at 2:50 AM, Tom Herbert [off-list ref] wrote:

I am concerned that we are overloading the skb->encpasulation

Guys, so to sum up yesterday's messages on this thread -- do folks
think we can come up with better/proper definition for the
skb->encapsulation bit, or we have to make this multiple bits, or we
have (hopefully not too non linear) dependancy on proper
definitions/usage of the skb->ip_summed field?


Or.

for instance if this is set in TX path meaning inner headers are valid,
this should also be true of RX. It might be better if this field
indicated characteristics of the packet independent of being in RX or
TX path. For checksum, maybe we should have a separate encap_checksum
field. Also, to be future proof may this should be two bits for the
devices that can verify checksums in multiple levels of encapsulations
(yes, I know this sounds absurd, but it's no more absurd than devices
vendors taking it upon themselves to parse to some restricted set of
encapsulations instead of just giving us the full packet checksum! :-)).

I hope to have patches soon on fixing CHECKSUM_COMPLETE, I think it
entails some more state in skb indicating offset and extent of
checksum value in the packet. An like a said, we need to get out of
the habit of stashing pseudo csums there (unless CHECKSUM_PARTIAL is
set).

quoted

Also for Tx, skb->encapsulation should be the indication to the
driver that it can use the inner headers (i.e. they are valid) in the skb
in order to offload the inner csum.