From: Jakub Kicinski <kuba@kernel.org>
To: "Nambiar, Amritha" <amritha.nambiar@intel.com>
Cc: Alexander H Duyck <alexander.duyck@gmail.com>,
<netdev@vger.kernel.org>, <davem@davemloft.net>,
<edumazet@google.com>, <pabeni@redhat.com>,
"Saeed Mahameed" <saeed@kernel.org>,
"Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Subject: Re: Kernel interface to configure queue-group parameters
Date: Fri, 24 Feb 2023 11:22:07 -0800 [thread overview]
Message-ID: <20230224112207.055165bd@kernel.org> (raw)
In-Reply-To: <34993e14-2c33-8eaf-67a9-e3412778e6f0@intel.com>
On Fri, 24 Feb 2023 01:14:15 -0800 Nambiar, Amritha wrote:
> On 2/16/2023 9:32 AM, Jakub Kicinski wrote:
> > On Thu, 16 Feb 2023 02:35:35 -0800 Nambiar, Amritha wrote:
> >> Right. Something like /sys/class/net/<iface>/napis/napi<0-N>
> >> Maybe, initially there would be as many napis as queues due to 1:1
> >> association, but as the queues bitmap is tuned for the napi, only those
> >> napis that have queue[s] associated with it would be exposed.
> >
> > Forget about using sysfs, please. We've been talking about making
> > "queues first class citizen", mapping to pollers is part of that
> > problem space. And it's complex enough to be better suited for netlink.
>
> Okay. Can ethtool netlink be an option for this? For example,
>
> ethtool --show-napis
> Lists all the napi instances and associated queue[s] list for each napi
> for the specified network device.
>
> ethtool --set-napi
> Configure the attributes (say, queue[s] list) for each napi
>
> napi <napi_id>
> The napi instance to configure
>
> queues <q_id1, q_id2, ...>
> The queue[s] that are to be serviced by the napi instance.
The netdev-genl family is a better target.
But the work is doing the refactoring within the kernel to abstract
all this stuff away from the drivers, so that the kernel has
a stronger model of queues. If we just expose the calls to the drivers
directly we'll end up with a lot of code duplication and not-so-subtle
differences between vendors :(
next prev parent reply other threads:[~2023-02-24 19:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 0:15 Kernel interface to configure queue-group parameters Nambiar, Amritha
2023-02-07 16:28 ` Alexander H Duyck
2023-02-09 0:36 ` Jakub Kicinski
2023-02-16 10:34 ` Nambiar, Amritha
2023-02-16 10:35 ` Nambiar, Amritha
2023-02-16 17:32 ` Jakub Kicinski
2023-02-24 9:14 ` Nambiar, Amritha
2023-02-24 19:22 ` Jakub Kicinski [this message]
2023-02-19 17:39 ` Alexander H Duyck
2023-02-24 9:17 ` 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=20230224112207.055165bd@kernel.org \
--to=kuba@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=amritha.nambiar@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeed@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 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.