From: "Arinzon, David" <darinzon@amazon.com>
To: Joe Damato <jdamato@fastly.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Agroskin, Shay" <shayagr@amazon.com>,
"Kiyanovski, Arthur" <akiyano@amazon.com>,
"Dagan, Noam" <ndagan@amazon.com>,
"Bshara, Saeed" <saeedb@amazon.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Kamal Heib <kheib@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
"Bernstein, Amit" <amitbern@amazon.com>
Subject: RE: [net-next 2/2] ena: Link queues to NAPIs
Date: Tue, 1 Oct 2024 15:50:24 +0000 [thread overview]
Message-ID: <26bda21325814a8cb11f997b80bf5262@amazon.com> (raw)
In-Reply-To: <ZvwHC6VLihXevnPo@LQ3V64L9R2>
> > > Link queues to NAPIs using the netdev-genl API so this information
> > > is queryable.
> > >
> > > $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml
> \
> > > --dump queue-get --json='{"ifindex": 2}'
> > >
> > > [{'id': 0, 'ifindex': 2, 'napi-id': 8201, 'type': 'rx'},
> > > {'id': 1, 'ifindex': 2, 'napi-id': 8202, 'type': 'rx'},
> > > {'id': 2, 'ifindex': 2, 'napi-id': 8203, 'type': 'rx'},
> > > {'id': 3, 'ifindex': 2, 'napi-id': 8204, 'type': 'rx'},
> > > {'id': 4, 'ifindex': 2, 'napi-id': 8205, 'type': 'rx'},
> > > {'id': 5, 'ifindex': 2, 'napi-id': 8206, 'type': 'rx'},
> > > {'id': 6, 'ifindex': 2, 'napi-id': 8207, 'type': 'rx'},
> > > {'id': 7, 'ifindex': 2, 'napi-id': 8208, 'type': 'rx'},
> > > {'id': 0, 'ifindex': 2, 'napi-id': 8201, 'type': 'tx'},
> > > {'id': 1, 'ifindex': 2, 'napi-id': 8202, 'type': 'tx'},
> > > {'id': 2, 'ifindex': 2, 'napi-id': 8203, 'type': 'tx'},
> > > {'id': 3, 'ifindex': 2, 'napi-id': 8204, 'type': 'tx'},
> > > {'id': 4, 'ifindex': 2, 'napi-id': 8205, 'type': 'tx'},
> > > {'id': 5, 'ifindex': 2, 'napi-id': 8206, 'type': 'tx'},
> > > {'id': 6, 'ifindex': 2, 'napi-id': 8207, 'type': 'tx'},
> > > {'id': 7, 'ifindex': 2, 'napi-id': 8208, 'type': 'tx'}]
> > >
> > > Signed-off-by: Joe Damato <jdamato@fastly.com>
> > > ---
> > > drivers/net/ethernet/amazon/ena/ena_netdev.c | 26
> > > +++++++++++++++++---
> > > 1 file changed, 22 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> > > b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> > > index e88de5e426ef..1c59aedaa5d5 100644
> > > --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> > > +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> > > @@ -1821,20 +1821,38 @@ static void ena_napi_disable_in_range(struct
> > > ena_adapter *adapter,
> > > int first_index,
> > > int count) {
> > > + struct napi_struct *napi;
> >
> > Is this variable necessary? It has been defined in the enable function
> > because it is needed in netif_queue_set_napi() API as well as in
> > napi_enable(), and it makes sense in order to avoid long lines In
> > here, the variable is only used in a call to napi_disable(), can the
> > code be kept as it is? don't see a need to shorten the napi_disable() call
> line.
>
> It is true that its only used to call napi_disable so if you prefer to have it
> removed let me know?
>
> I think it looks nicer with the variable, but it's your driver.
>
> > > int i;
> > >
> > > - for (i = first_index; i < first_index + count; i++)
> > > - napi_disable(&adapter->ena_napi[i].napi);
> > > + for (i = first_index; i < first_index + count; i++) {
> > > + napi = &adapter->ena_napi[i].napi;
> > > + if (!ENA_IS_XDP_INDEX(adapter, i)) {
> > > + netif_queue_set_napi(adapter->netdev, i,
> > > + NETDEV_QUEUE_TYPE_TX, NULL);
> > > + netif_queue_set_napi(adapter->netdev, i,
> > > + NETDEV_QUEUE_TYPE_RX, NULL);
> > > + }
> > > + napi_disable(napi);
> > > + }
> > > }
> > >
> > > static void ena_napi_enable_in_range(struct ena_adapter *adapter,
> > > int first_index,
> > > int count) {
> > > + struct napi_struct *napi;
> > > int i;
> > >
> > > - for (i = first_index; i < first_index + count; i++)
> > > - napi_enable(&adapter->ena_napi[i].napi);
> > > + for (i = first_index; i < first_index + count; i++) {
> > > + napi = &adapter->ena_napi[i].napi;
> > > + napi_enable(napi);
> > > + if (!ENA_IS_XDP_INDEX(adapter, i)) {
> >
> > Can you share some info on why you decided to set the queue to napi
> > association only in non-xdp case?
> > In XDP, there's a napi poll function that's executed and it runs on the TX
> queue.
> > I am assuming that it's because XDP is not yet supported in the
> > framework? If so, there's a need to add an explicit comment above if
> > (!ENA_IS_XDP_INDEX(adapter, i)) { explaining this in order to avoid
> confusion with the rest of the code.
>
> Yes; it is skipped for XDP queues, but they could be supported in the future.
>
> Other drivers that support this API work similarly (see also: bnxt, ice, mlx4,
> etc).
>
> > > + netif_queue_set_napi(adapter->netdev, i,
> > > + NETDEV_QUEUE_TYPE_RX, napi);
> > > + netif_queue_set_napi(adapter->netdev, i,
> > > + NETDEV_QUEUE_TYPE_TX, napi);
> > > + }
> > > + }
> > > }
> > >
> > > /* Configure the Rx forwarding */
> > > --
> > > 2.43.0
> >
> > Thank you for uploading this patch.
>
> Can you please let me know (explicitly) if you want me to send a second
> revision (when net-next allows for it) to remove the 'struct napi_struct' and
> add a comment as described above?
Yes, I would appreciate that.
I guess the `struct napi_struct` is OK, this way both functions will look the same.
Regarding the comment, yes please, something like /* This API is supported for non-XDP queues only */ in both places.
I also added a small request to preserve reverse christmas tree order on patch 1/2 in the series.
Thank you again for the patches in the driver.
next prev parent reply other threads:[~2024-10-01 15:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 19:56 [net-next 0/2] ena: Link IRQs, queues, and NAPI instances Joe Damato
2024-09-30 19:56 ` [net-next 1/2] ena: Link IRQs to " Joe Damato
2024-10-01 8:57 ` Arinzon, David
2024-10-01 16:18 ` Joe Damato
2024-09-30 19:56 ` [net-next 2/2] ena: Link queues to NAPIs Joe Damato
2024-10-01 9:06 ` Arinzon, David
2024-10-01 14:28 ` Joe Damato
2024-10-01 15:50 ` Arinzon, David [this message]
2024-10-01 16:21 ` Joe Damato
-- strict thread matches above, loose matches on Subject: below --
2024-10-01 16:40 Arinzon, David
2024-10-01 18:07 ` Joe Damato
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=26bda21325814a8cb11f997b80bf5262@amazon.com \
--to=darinzon@amazon.com \
--cc=akiyano@amazon.com \
--cc=amitbern@amazon.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jdamato@fastly.com \
--cc=kheib@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ndagan@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedb@amazon.com \
--cc=shayagr@amazon.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.