netdev - Re: [PATCH net-next] tsnep: Link queues to NAPIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250113143109.60afa59a@kernel.org>
Date: Mon, 13 Jan 2025 14:31:09 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Joe Damato <jdamato@...tly.com>
Cc: Gerhard Engleder <gerhard@...leder-embedded.com>,
 magnus.karlsson@...el.com, andrew@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tsnep: Link queues to NAPIs

On Mon, 13 Jan 2025 14:20:56 -0800 Joe Damato wrote:
> > 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.  
> 
> Sorry to be an annoyance, but could this be added to docs somewhere?
> 
> I think I did the AF_XDP case I did two different ways; exported for
> mlx5, but (iiuc) not exporter for igc.

Yes, I think netdev.yaml is the best place to document the meaning of
rx and tx queue type. Are you going to take a stab at it?

> I don't want to hijack Gerhard's thread; maybe I should start a new
> thread to double check that the drivers I modified are right?

Ideally we'd have a test for this. How is your Python?
tools/testing/selftests/drivers/net/queues.py