[Intel-wired-lan] [PATCH V2] ixgbe: Handle extended IPv6 headers in tx path

[Rustad, Mark D]

Tom Herbert <tom at herbertland.com> wrote:

> The _only_ thing that is authoritative in checksum offload are the
> values of csum_start and csum_offset. If a driver ensures that
> checksum is properly calculated from start and set at the offset, then
> driver is implementing correct behavior and has no additional
> requirements as far as the stack is concerned. Neither does the stack
> does not care if this is done with offload to the device or by calling
> skb_checksum_help.
> 
>>>>> The problem is there are scenarios here where a checksum shouldn't be
>>>>> computed.  If for example the frame is fragmented we should be
>>>>> displaying some sort of error message and not computing the checksum
>>>>> because no matter what we compute it isn't going to be valid.
>>>> If the stack is sending fragments with CHECKSUM_PARTIAL set then that
>>>> is a bug higher in the stack-- the driver does not need to worry about
>>>> that.
>>> 
>>> Right, but it is still something that needs to get fixed.  By
>>> triggering the dev_warn here we at least create visibility that
>>> something has gone horribly wrong.
>> 
>> Right. It needs to be fixed one way or another. In some cases it would be the stack that needs a fix, in some cases a call to skb_checksum_help might be needed or maybe something else.
> 
> Are you actually seeing fragments with CHECKSUM_PARTIAL set?

I haven't seen any yet and I don't expect to. But the dev_warn that was in this area prior to the current patch was triggered when I first sent IPv6 packets with extended headers. Yes, the checksum was not computed, but there also was a warning in the log. Likewise when I didn't have the encapsulation working for this case, when I tried it I got a warning in the log. So it does indicate when things are broken and so is useful. Of course these were fixed by the driver patch because they were the result of deficiencies in the driver, which you first spotted by code inspection.

--
Mark Rustad, Networking Division, Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20151117/9596ceba/attachment.asc>