netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "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: Fri, 28 Jul 2023 16:09:25 -0700	[thread overview]
Message-ID: <20230728160925.3a080631@kernel.org> (raw)
In-Reply-To: <44c5024a-d533-0ae4-355a-c568b67b1964@intel.com>

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.

  reply	other threads:[~2023-07-28 23:09 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 [this message]
2023-07-31 23:48                   ` Nambiar, Amritha
2023-08-02  0:26                   ` David Ahern
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=20230728160925.3a080631@kernel.org \
    --to=kuba@kernel.org \
    --cc=amritha.nambiar@intel.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.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;
as well as URLs for NNTP newsgroup(s).