From: Jakub Kicinski <kuba@kernel.org>
To: Cosmin Ratiu <cratiu@nvidia.com>
Cc: "daniel.zahka@gmail.com" <daniel.zahka@gmail.com>,
"willemdebruijn.kernel@gmail.com"
<willemdebruijn.kernel@gmail.com>,
"edumazet@google.com" <edumazet@google.com>,
Boris Pismenny <borisp@nvidia.com>,
"kuniyu@google.com" <kuniyu@google.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC net-next 0/6] psp: use virt cookie as Rx steering hint
Date: Tue, 25 Aug 2026 11:55:18 -0700 [thread overview]
Message-ID: <20260825115518.2b925e90@kernel.org> (raw)
In-Reply-To: <7bddbd246387fe4dfdc1e638b50d44a73aecdc83.camel@nvidia.com>
On Tue, 25 Aug 2026 09:52:09 +0000 Cosmin Ratiu wrote:
> Option 1 would be to only set req_qid on _changes_ (edge transitions)
> and keep it 0 otherwise. Also make it mean queue = req_qid - 1 to allow
> the use of queue 0. Ideally, only the first packet in each direction
> would have req_qid != 0. These packets cannot be decapped and cannot go
> through HW GRO, but all subsequent ones with req_qid == 0 may. dst_qid
> is of course != 0 in all packets and is honored.
>
> But then you need to make sure those packets aren't lost, and maybe
> retransmit req_qid until it gets received. I thought about it a bit,
> maybe using TCP acks as an indication? Or just trying best-effort a
> couple of times...
>
> Option 2 would be to just disallow HW GRO with req_qid.
I'd go with Option 2 FWIW and revisit it later if we find out that more
NICs need some sort of workaround.
> And option 3: sport selection to get the desired RSS result makes this
> interaction non-existent.
next prev parent reply other threads:[~2026-08-25 18:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 22:55 [RFC net-next 0/6] psp: use virt cookie as Rx steering hint Jakub Kicinski
2026-08-22 22:55 ` [RFC net-next 1/6] psp: steer Rx queues with the virtualization cookie Jakub Kicinski
2026-08-23 15:31 ` Daniel Zahka
2026-08-24 15:01 ` Jakub Kicinski
2026-08-24 15:09 ` Cosmin Ratiu
2026-08-24 15:19 ` Jakub Kicinski
2026-08-23 18:18 ` Willem de Bruijn
2026-08-22 22:55 ` [RFC net-next 2/6] netdevsim: support PSP VC based queue steering Jakub Kicinski
2026-08-22 22:55 ` [RFC net-next 3/6] selftests: drv-net: psp: move the PSP test plumbing into psp_lib.py Jakub Kicinski
2026-08-22 22:55 ` [RFC net-next 4/6] selftests: drv-net: psp_steer: test PSP VC based queue steering Jakub Kicinski
2026-08-22 22:55 ` [RFC net-next 5/6] selftests: drv-net: psp_steer: test where PSP steering sits in the Rx pipeline Jakub Kicinski
2026-08-22 22:55 ` [RFC net-next 6/6] selftests: drv-net: psp_steer: cover corner cases and races Jakub Kicinski
2026-08-23 17:48 ` [RFC net-next 0/6] psp: use virt cookie as Rx steering hint Willem de Bruijn
2026-08-24 15:05 ` Cosmin Ratiu
2026-08-25 9:52 ` Cosmin Ratiu
2026-08-25 18:55 ` Jakub Kicinski [this message]
2026-08-24 15:11 ` Jakub Kicinski
2026-08-24 18:04 ` Willem de Bruijn
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=20260825115518.2b925e90@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=daniel.zahka@gmail.com \
--cc=edumazet@google.com \
--cc=kuniyu@google.com \
--cc=netdev@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox