From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Simon Horman <simon.horman@corigine.com>,
Paolo Abeni <pabeni@redhat.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 08:38:13 -0700 [thread overview]
Message-ID: <20230524083813.65cdee0d@kernel.org> (raw)
In-Reply-To: <CAF=yD-JH2NHTXCg-Z=cUw-JK0g9Y9pb-pcyboq5AkES+ohShkg@mail.gmail.com>
On Wed, 24 May 2023 11:33:15 -0400 Willem de Bruijn wrote:
> The OCP draft spec already has this wording, which covers UDP:
>
> "RSS defines two rules to derive queue selection input in a
> flow-affine manner from packet headers. Selected fields of the headers
> are extracted and concatenated into a byte array. If the packet is
> IPv4 or IPv6, not fragmented, and followed by a transport layer
> protocol with ports, such as TCP and UDP, then extract the
> concatenated 4-field byte array { source address, destination address,
> source port, destination port }. Else, if the packet is IPv4 or IPv6,
> extract 2-field byte array { source address, destination address }.
> IPv4 packets are considered fragmented if the more fragments bit is
> set or the fragment offset field is non-zero."
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).
next prev parent reply other threads:[~2023-05-24 15:38 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 [this message]
2023-05-24 16:14 ` Paolo Abeni
2023-05-24 16:28 ` Jakub Kicinski
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=20230524083813.65cdee0d@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.