Re: [Patch net v3] mlx5: force CHECKSUM_NONE for short ethernet frames

On 12/04/2018 12:35 PM, Cong Wang wrote:

On Tue, Dec 4, 2018 at 11:17 AM Saeed Mahameed
[off-list ref] wrote:

quoted

On Mon, Dec 3, 2018 at 11:52 PM Eric Dumazet [off-list ref] wrote:

quoted

On Mon, Dec 3, 2018 at 11:30 PM Cong Wang [off-list ref] wrote:

quoted

On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet [off-list ref] wrote:

quoted

The hardware has probably validated the L3 & L4 checksum just fine.

Note that if ip_summed is CHECKSUM_UNNECESSARY, the padding bytes (if any)
have no impact on the csum that has been verified by the NIC.

Why? Why does the hardware validates L3/L4 checksum when it
supplies a full-packet checksum? What's its point here?

The point is that the driver author can decide what is best.

For native IP+TCP or IP+UDP, the NIC has the ability to fully
understand the packet and fully validate the checksum.

Also for Native IP4 and IP6 plain L3 packets.
The Hardware validates the csum when it can, and always provides
checksum complete for all packets.
One of the reason to validate is that sometimes we want to skip
checksum complete, but still leverage the hw validation,
like in your patch :), or LRO case, or many other cases in other
kernels/OSes/drivers.

This sounds wrong to me too.

If the HW already validates it, the software doesn't need to do it,
therefore must skip hw csum for performance gain.,

quoted

So i agree with Eric, let's jump to checksum_unnecessary for short packets.

This is odd, if Eric is right, then we should completely get rid of
CHECKSUM_COMPLETE. Short packets are not exceptions.

I still don't understand why people including Eric kept fixing this
thing which could be just removed from the very beginning.
Sounds like nobody even looked into it until my patch.

Erm I never suggested to get rid of CHECKSUM_COMPLETE...
My suggestion was to reorder the mlx5 logic to match mlx4 one.

CHECKSUM_COMPLETE is very nice _when_/_if_ the NIC is unable to
fully dissect a packet and validate L4, as a fallback.

I am pretty sure for example that IP reassembly can benefit from CHECKSUM_COMPLETE.
(Although for some reason mlx4 code does not handle IPv6 fragments in its CHECKSUM_COMPLETE path)