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 14:59:08 -0700 [thread overview]
Message-ID: <20230728145908.2d94c01f@kernel.org> (raw)
In-Reply-To: <20230712165326.71c3a8ad@kernel.org>
On Wed, 12 Jul 2023 16:53:26 -0700 Jakub Kicinski wrote:
> > The napi pointer in the queue structs would give the napi<->queue
> > mapping, I still need to walk the queues of a NAPI (when there are
> > multiple queues for the NAPI), example:
> > 'napi-id': 600, 'rx-queues': [7,6,5], 'tx-queues': [7,6,5]
> >
> > in which case I would have a list of netdev queue structs within the
> > napi_struct (instead of the list of queue indices that I currently have)
> > to avoid memory allocation.
> >
> > Does this sound right?
>
> yes, I think that's fine.
>
> If we store the NAPI pointer in the queue struct, we can still generate
> the same dump with the time complexity of #napis * (#max_rx + #max_tx).
> Which I don't think is too bad. Up to you.
The more I think about it the more I feel like we should dump queues
and NAPIs separately. And the queue can list the NAPI id of the NAPI
instance which services it.
Are you actively working on this or should I take a stab?
next prev parent reply other threads:[~2023-07-28 21:59 UTC|newest]
Thread overview: 30+ 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 [this message]
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
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 7:50 ` Dan Carpenter
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=20230728145908.2d94c01f@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 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.