From: David Ahern <dsahern@kernel•org>
To: Jakub Kicinski <kuba@kernel•org>,
"Nambiar, Amritha" <amritha.nambiar@intel•com>
Cc: netdev@vger•kernel.org, davem@davemloft•net, sridhar.samudrala@intel•com
Subject: Re: [net-next/RFC PATCH v1 1/4] net: Introduce new napi fields for rx/tx queues
Date: Tue, 1 Aug 2023 18:26:26 -0600 [thread overview]
Message-ID: <802d3a2f-c2fb-2e11-b678-e8716ef93f12@kernel.org> (raw)
In-Reply-To: <20230728160925.3a080631@kernel.org>
On 7/28/23 5:09 PM, Jakub Kicinski wrote:
> On Fri, 28 Jul 2023 15:37:14 -0700 Nambiar, Amritha wrote:
>> Hi Jakub, I have the next version of patches ready (I'll send that in a
>> bit). I suggest if you could take a look at it and let me know your
>> thoughts and then we can proceed from there.
>
> Great, looking forward.
>
>> About dumping queues and NAPIs separately, are you thinking about having
>> both per-NAPI and per-queue instances, or do you think only one will
>> suffice. The plan was to follow this work with a 'set-napi' series,
>> something like,
>> set-napi <napi_id> queues <q_id1, q_id2, ...>
>> to configure the queue[s] that are to be serviced by the napi instance.
>>
>> In this case, dumping the NAPIs would be beneficial especially when
>> there are multiple queues on the NAPI.
>>
>> WRT per-queue, are there a set of parameters that needs to exposed
>> besides what's already handled by ethtool...
>
> Not much at this point, maybe memory model. Maybe stats if we want to
> put stats in the same command. But the fact that sysfs has a bunch of
> per queue attributes makes me think that sooner or later we'll want
> queue as a full object in netlink. And starting out that way makes
> the whole API cleaner, at least in my opinion.
>
> If we have another object which wants to refer to queues (e.g. page
> pool) it's easier to express the topology when it's clear what is an
> object and what's just an attribute.
>
>> Also, to configure a queue
>> on a NAPI, set-queue <qid> <napi_id>, the existing NAPIs would have to
>> be looked up from the queue parameters dumped.
>
> The look up should not be much of a problem.
>
> And don't you think that:
>
> set-queue queue 1 napi-id 101
> set-queue queue 2 napi-id 101
>
> is more natural than:
>
> set-napi napi-id 101 queues [1, 2]
>
> Especially in presence of conflicts. If user tries:
>
> set-napi napi-id 101 queues [1, 2]
> set-napi napi-id 102 queues [1, 2]
>
> Do both napis now serve those queues? May seem obvious to us, but
> "philosophically" why does setting an attribute of object 102 change
> attributes of object 101?
>
> If we ever gain the ability to create queues it will be:
>
> create-queue napi-id xyz
>
> which also matches set-queue more nicely than napi base API.
>
I take it you have this path in mind as a means of creating
"specialized" queues (e.g., io_uring and Rx ZC). Any slides or notes on
the bigger picture?
next prev parent reply other threads:[~2023-08-02 0:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 17:42 [net-next/RFC PATCH v1 0/4] Introduce napi queues support Amritha Nambiar
2023-06-01 17:42 ` [net-next/RFC PATCH v1 1/4] net: Introduce new napi fields for rx/tx queues Amritha Nambiar
2023-06-03 6:06 ` Jakub Kicinski
2023-07-12 20:09 ` Nambiar, Amritha
2023-07-12 21:14 ` Jakub Kicinski
2023-07-12 23:11 ` Nambiar, Amritha
2023-07-12 23:53 ` Jakub Kicinski
2023-07-28 21:59 ` Jakub Kicinski
2023-07-28 22:37 ` Nambiar, Amritha
2023-07-28 23:09 ` Jakub Kicinski
2023-07-31 23:48 ` Nambiar, Amritha
2023-08-02 0:26 ` David Ahern [this message]
2023-08-02 0:50 ` Jakub Kicinski
2023-06-01 17:42 ` [net-next/RFC PATCH v1 2/4] net: Add support for associating napi with queue[s] Amritha Nambiar
2023-06-02 15:42 ` Simon Horman
2023-07-12 19:53 ` Nambiar, Amritha
2023-06-03 6:31 ` Paolo Abeni
2023-07-12 19:56 ` Nambiar, Amritha
2023-06-01 17:42 ` [net-next/RFC PATCH v1 3/4] netdev-genl: Introduce netdev dump ctx Amritha Nambiar
2023-06-01 17:42 ` [net-next/RFC PATCH v1 4/4] netdev-genl: Add support for exposing napi info from netdev Amritha Nambiar
2023-06-02 15:47 ` Simon Horman
2023-06-03 6:08 ` Jakub Kicinski
2023-07-12 20:05 ` Nambiar, Amritha
2023-07-12 19:54 ` Nambiar, Amritha
2023-06-03 6:17 ` Jakub Kicinski
2023-07-12 20:10 ` Nambiar, Amritha
2023-07-12 21:19 ` Jakub Kicinski
2023-06-03 6:00 ` [net-next/RFC PATCH v1 0/4] Introduce napi queues support Jakub Kicinski
2023-07-12 19:52 ` Nambiar, Amritha
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=802d3a2f-c2fb-2e11-b678-e8716ef93f12@kernel.org \
--to=dsahern@kernel$(echo .)org \
--cc=amritha.nambiar@intel$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=kuba@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sridhar.samudrala@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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