All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Joe Damato <jdamato@fastly.com>
Cc: Gerhard Engleder <gerhard@engleder-embedded.com>,
	magnus.karlsson@intel.com, andrew@lunn.ch, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] tsnep: Link queues to NAPIs
Date: Mon, 13 Jan 2025 13:56:09 -0800	[thread overview]
Message-ID: <20250113135609.13883897@kernel.org> (raw)
In-Reply-To: <Z4WKHnDG9VSMe5OD@LQ3V64L9R2>

On Mon, 13 Jan 2025 13:48:14 -0800 Joe Damato wrote:
> > > The changes generally look OK to me (it seems RTNL is held on all
> > > paths where this code can be called from as far as I can tell), but
> > > there was one thing that stood out to me.
> > > 
> > > AFAIU, drivers avoid marking XDP queues as NETDEV_QUEUE_TYPE_RX
> > > or NETDEV_QUEUE_TYPE_TX. I could be wrong, but that was my
> > > understanding and I submit patches to several drivers with this
> > > assumption.
> > > 
> > > For example, in commit b65969856d4f ("igc: Link queues to NAPI
> > > instances"), I unlinked/linked the NAPIs and queue IDs when XDP was
> > > enabled/disabled. Likewise, in commit 64b62146ba9e ("net/mlx4: link
> > > NAPI instances to queues and IRQs"), I avoided the XDP queues.
> > > 
> > > If drivers are to avoid marking XDP queues as NETDEV_QUEUE_TYPE_RX
> > > or NETDEV_QUEUE_TYPE_TX, perhaps tsnep needs to be modified
> > > similarly?  
> > 
> > With 5ef44b3cb4 ("xsk: Bring back busy polling support") the linking of
> > the NAPIs is required for XDP/XSK. So it is strange to me if for XDP/XSK
> > the NAPIs should be unlinked. But I'm not an expert, so maybe there is
> > a reason why.
> > 
> > I added Magnus, maybe he knows if XSK queues shall still be linked to
> > NAPIs.  
> 
> OK, so I think I was probably just wrong?
> 
> I looked at bnxt and it seems to mark XDP queues, which means
> probably my patches for igc, ena, and mlx4 need to be fixed and the
> proposed patch I have for virtio_net needs to be adjusted.
> 
> I can't remember now why I thought XDP queues should be avoided. I
> feel like I read that or got that as feedback at some point, but I
> can't remember now. Maybe it was just one driver or something I was
> working on and I accidentally thought it should be avoided
> everywhere? Not sure.
> 
> Hopefully some one can give a definitive answer on this one before I
> go through and try to fix all the drivers I modified :|

XDP and AF_XDP are different things. The XDP part of AF_XDP is to some
extent for advertising purposes :) If memory serves me well:

XDP Tx -> these are additional queues automatically allocated for
          in-kernel XDP, allocated when XDP is attached on Rx.
          These should _not_ be listed in netlink queue, or NAPI;
          IOW should not be linked to NAPI instances.
XDP Rx -> is not a thing, XDP attaches to stack queues, there are no
          dedicated XDP Rx queues
AF_XDP -> AF_XDP "takes over" stack queues. It's a bit of a gray area.
          I don't recall if we made a call on these being linked, but
          they could probably be listed like devmem as a queue with
          an extra attribute, not a completely separate queue type.

  reply	other threads:[~2025-01-13 21:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 22:39 [PATCH net-next] tsnep: Link queues to NAPIs Gerhard Engleder
2025-01-13 12:24 ` Alexander Lobakin
2025-01-13 19:59 ` Joe Damato
2025-01-13 20:32   ` Gerhard Engleder
2025-01-13 21:48     ` Joe Damato
2025-01-13 21:56       ` Jakub Kicinski [this message]
2025-01-13 22:20         ` Joe Damato
2025-01-13 22:31           ` Jakub Kicinski
2025-01-13 22:36             ` Joe Damato
2025-01-14 20:58         ` Gerhard Engleder
2025-01-14 21:22           ` Jakub Kicinski
2025-01-14 23:00 ` patchwork-bot+netdevbpf
2025-01-14 23:05 ` 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=20250113135609.13883897@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gerhard@engleder-embedded.com \
    --cc=jdamato@fastly.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.