On Thu, Jan 31, 2019 at 4:06 PM Saeed Mahameed <sae...@mellanox.com> wrote: > > On Thu, 2019-01-31 at 11:42 -0800, Eric Dumazet wrote: > > On Thu, Jan 31, 2019 at 11:27 AM Saeed Mahameed <sae...@mellanox.com> > > wrote: > > > Are you sure ? you are claiming that the hardware will skip csum > > > complete i.e cqe->checksum will be 0xffff for padded short IP > > > frames. > > > i don't think this is the case, the whole bug is that the hw does > > > provide a partial cqe->checksum (i.e doesn't included the padding > > > bytes) even for short eth frames. > > > > If the padding is not included, then cqe->checksum is 0xFFFF for > > correctly received frames. > > > > Otherwise, what would be cqe->checksum in this case ? A random value > > ? > > the actual checksum of IP headers+IP payload, while ignoring the > padding bytes, which is the bug, let me double check.. > >
Ok, just verified, csum complete (cqe->checksum) is provided and valid for non-TCP/UDP ip packets, (on specific ConnectX3 HWs) e.g. ICMP packets or IP fragments go through csum complete, that being said, looking at the code before my patch. when cqe->checksum complete is not valid a IP non-TCP/UDP packet will report csum NONE, which means my TODO comment is valid even without my patch :). We can remove the TODO, although i am fine with it if it kept there, since it is valid, but we must add a future optimization task (to tariq's backlog ;)) for IP non-TCP/UDP traffic to check for csum unnecessary when csum complete is not an option. Thanks, Saeed.
