All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>, saeedm@dev.mellanox.co.il
Cc: Eric Dumazet <edumazet@google.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Tariq Toukan <tariqt@mellanox.com>
Subject: Re: [Patch net v3] mlx5: force CHECKSUM_NONE for short ethernet frames
Date: Tue, 4 Dec 2018 13:16:35 -0800	[thread overview]
Message-ID: <325adc28-b9b7-947c-a3a8-ae848c224957@gmail.com> (raw)
In-Reply-To: <CAM_iQpUqhaJ0_hJZfZoJtu50K5bae0oR5f1jAUVR1F7id6YLzQ@mail.gmail.com>



On 12/04/2018 12:35 PM, Cong Wang wrote:
> On Tue, Dec 4, 2018 at 11:17 AM Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>>
>> On Mon, Dec 3, 2018 at 11:52 PM Eric Dumazet <edumazet@google.com> wrote:
>>>
>>> On Mon, Dec 3, 2018 at 11:30 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>>
>>>> On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet <edumazet@google.com> wrote:
>>>>>
>>>>> 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.,
> 
> 
>>
>> 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)

  reply	other threads:[~2018-12-04 21:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04  6:14 [Patch net v3] mlx5: force CHECKSUM_NONE for short ethernet frames Cong Wang
2018-12-04  6:34 ` Eric Dumazet
2018-12-04  6:48   ` Cong Wang
     [not found]     ` <CANn89iK0j=2LYK=szVO+Fpg1-tX=wSz+ghZx8RnwZSEbxZjf5w@mail.gmail.com>
2018-12-04  7:09       ` Eric Dumazet
2018-12-04  7:29       ` Cong Wang
2018-12-04  7:51         ` Eric Dumazet
2018-12-04 19:17           ` Saeed Mahameed
2018-12-04 20:35             ` Cong Wang
2018-12-04 21:16               ` Eric Dumazet [this message]
2018-12-04 21:20                 ` Cong Wang
2018-12-05  0:59               ` Saeed Mahameed
2018-12-05  2:48                 ` Cong Wang
2018-12-04 20:31           ` Cong Wang
2018-12-04 19:02 ` Saeed Mahameed
2018-12-04 20:44 ` Cong Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=325adc28-b9b7-947c-a3a8-ae848c224957@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@dev.mellanox.co.il \
    --cc=saeedm@mellanox.com \
    --cc=tariqt@mellanox.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.