netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Mina Almasry <almasrymina@google.com>
Cc: netdev@vger.kernel.org, hawk@kernel.org,
	ilias.apalodimas@linaro.org, aleksander.lobakin@intel.com,
	linyunsheng@huawei.com
Subject: Re: [RFC net-next 04/13] net: page_pool: id the page pools
Date: Thu, 17 Aug 2023 17:08:48 -0700	[thread overview]
Message-ID: <20230817170848.4f96f9c5@kernel.org> (raw)
In-Reply-To: <CAHS8izOu=DxeRdD7Gdt-N2qvH_Nnwpcem1KkNgjOLeWzHZ_5JQ@mail.gmail.com>

On Thu, 17 Aug 2023 14:56:01 -0700 Mina Almasry wrote:
> Sorry maybe I'm missing something, but it's a bit curious to me that
> this ID is needed.

Right.. now I realize that I haven't explained the queue side.

I expect a similar API will be added to dump queue info, and then page
pool ID will be added to the queue object, to link which queue is being
fed from which page pool. I guess I should have said that in the cover
letter...

> An rx queue can only ever have 1 page-pool
> associated with it at a time, right? Could you instead add a pointer
> to the page_pool into 'struct netdev_rx_queue', 

100% my intention, which is why I moved the location of that struct
recently :)

> and then page-pool can be referred to by the netdev id & the rx-queue
> number? 

And use/type (headers vs payloads). And then nothing stops a driver from
using one page pool for multiple queues of the same type within a NAPI.
And then the page pools can die and linger (see patch 11).

> Wouldn't that make the implementation much simpler? I also believe
> the userspace refers to the rx-queue by its index number for the
> ethtool APIs like adding flow steering rules, so extending that to
> here maybe makes sense.

  reply	other threads:[~2023-08-18  0:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16 23:42 [RFC net-next 00/13] net: page_pool: add netlink-based introspection Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 01/13] net: page_pool: split the page_pool_params into fast and slow Jakub Kicinski
2023-08-17  9:31   ` Jesper Dangaard Brouer
2023-08-17  9:35   ` Ilias Apalodimas
2023-08-17 21:28   ` Mina Almasry
2023-08-16 23:42 ` [RFC net-next 02/13] net: page_pool: avoid touching slow on the fastpath Jakub Kicinski
2023-08-17  9:32   ` Jesper Dangaard Brouer
2023-08-17  9:38   ` Ilias Apalodimas
2023-08-17 21:31   ` Mina Almasry
2023-08-16 23:42 ` [RFC net-next 03/13] net: page_pool: factor out uninit Jakub Kicinski
2023-08-17  7:40   ` Ilias Apalodimas
2023-08-17 16:25     ` Jakub Kicinski
2023-08-17 16:53       ` Ilias Apalodimas
2023-08-16 23:42 ` [RFC net-next 04/13] net: page_pool: id the page pools Jakub Kicinski
2023-08-17 21:56   ` Mina Almasry
2023-08-18  0:08     ` Jakub Kicinski [this message]
2023-08-16 23:42 ` [RFC net-next 05/13] net: page_pool: record pools per netdev Jakub Kicinski
2023-08-17  7:26   ` Simon Horman
2023-08-17 16:22     ` Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 06/13] net: page_pool: stash the NAPI ID for easier access Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 07/13] eth: link netdev to pp Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 08/13] net: page_pool: add nlspec for basic access to page pools Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 09/13] net: page_pool: implement GET in the netlink API Jakub Kicinski
2023-08-16 23:42 ` [RFC net-next 10/13] net: page_pool: add netlink notifications for state changes Jakub Kicinski
2023-08-16 23:43 ` [RFC net-next 11/13] net: page_pool: report when page pool was destroyed Jakub Kicinski
2023-08-16 23:43 ` [RFC net-next 12/13] net: page_pool: expose page pool stats via netlink Jakub Kicinski
2023-08-16 23:43 ` [RFC net-next 13/13] tools: netdev: regen after page pool changes Jakub Kicinski
2023-08-17 21:21 ` [RFC net-next 00/13] net: page_pool: add netlink-based introspection Mina Almasry
2023-08-18  0:13   ` Jakub Kicinski

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=20230817170848.4f96f9c5@kernel.org \
    --to=kuba@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=almasrymina@google.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=linyunsheng@huawei.com \
    --cc=netdev@vger.kernel.org \
    /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).