From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Simon Horman <simon.horman@corigine.com>,
Louis Peens <louis.peens@corigine.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, oss-drivers@corigine.com,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic
Date: Wed, 24 May 2023 09:28:39 -0700 [thread overview]
Message-ID: <20230524092839.2688a15d@kernel.org> (raw)
In-Reply-To: <2ecb3189855ceb4f7399271bf99af5a27926e59c.camel@redhat.com>
On Wed, 24 May 2023 18:14:55 +0200 Paolo Abeni wrote:
> > Ugh, that's what I thought. I swear I searched it for "fragment"
> > yesterday and the search came up empty. I blame google docs :|
> >
> > We should probably still document the recommendation that if the NIC
> > does not comply and hashes on ports with MF set - it should disable
> > UDP hashing by default (in kernel docs).
>
> FTR, the above schema could still move the same flow on different
> queues - if some datagrams in the given flow are fragmented and some
> are not.
Ah, you're right.
> Out of sheer ignorance I really don't know if/how many NICs implement
> RSS hashing with the above schema (using different data according to
> the IP header fragments related fields). I'm guessing some (most?) use
> a simpler schema (always L4 if available or never L4).
>
> I *think* we could as well suggest always using L4 for UDP. If users
> care about fragments they will have to explicitly deal with them
> anyway.
Makes sense. QUIC changed the math on how likely UDP fragmentation is.
next prev parent reply other threads:[~2023-05-24 16:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 14:13 [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic Louis Peens
2023-05-23 10:49 ` Paolo Abeni
2023-05-23 21:20 ` Jakub Kicinski
2023-05-24 11:30 ` Simon Horman
2023-05-24 15:22 ` Jakub Kicinski
2023-05-24 15:33 ` Willem de Bruijn
2023-05-24 15:38 ` Jakub Kicinski
2023-05-24 16:14 ` Paolo Abeni
2023-05-24 16:28 ` Jakub Kicinski [this message]
2023-05-24 3:40 ` patchwork-bot+netdevbpf
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=20230524092839.2688a15d@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=louis.peens@corigine.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=pabeni@redhat.com \
--cc=simon.horman@corigine.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@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.