On Thu, 13 Jun 2019 at 16:11, Björn Töpel <bjorn.topel@xxxxxxxxx> wrote: > > > On 2019-06-13 16:01, Maxim Mikityanskiy wrote: > > On 2019-06-13 15:58, Björn Töpel wrote: > >> On Wed, 12 Jun 2019 at 22:49, Jakub Kicinski > >> <jakub.kicinski@xxxxxxxxxxxxx> wrote: > >>> > >>> On Wed, 12 Jun 2019 15:56:33 +0000, Maxim Mikityanskiy wrote: > >>>> UAPI is not changed, XSK RX queues are exposed to the kernel. The lower > >>>> half of the available amount of RX queues are regular queues, and the > >>>> upper half are XSK RX queues. > >>> > >>> If I have 32 queues enabled on the NIC and I install AF_XDP socket on > >>> queue 10, does the NIC now have 64 RQs, but only first 32 are in the > >>> normal RSS map? > >>> > >> > >> Additional, related, question to Jakub's: Say that I'd like to hijack > >> all 32 Rx queues of the NIC. I create 32 AF_XDP socket and attach them > >> in zero-copy mode to the device. What's the result? > > > > There are 32 regular RX queues (0..31) and 32 XSK RX queues (32..63). If > > you want 32 zero-copy AF_XDP sockets, you can attach them to queues > > 32..63, and the regular traffic won't be affected at all. > > > Thanks for getting back! More questions! > > Ok, so I cannot (with zero-copy) get the regular traffic into AF_XDP > sockets? > > How does qids map? Can I only bind a zero-copy socket to qid 32..63 in > the example above? > > Say that I have a a copy-mode AF_XDP socket bound to queue 2. In this > case I will receive the regular traffic from queue 2. Enabling zero-copy > for the same queue, will this give an error, or receive AF_XDP specific > traffic from queue 2+32? Or return an error, and require an explicit > bind to any of the queues 32..63? > > Let me expand a bit on why I'm asking these qid questions. It's unfortunate that vendors have different view/mapping on "qids". For Intel, we allow to bind a zero-copy socket to all Rx qids. For Mellanox, a certain set of qids are allowed for zero-copy sockets. This highlights a need for a better abstraction for queues than "some queue id from ethtool". This will take some time, and I think that we have to accept for now that we'll have different behavior/mapping for zero-copy sockets on different NICs. Let's address this need for a better queue abstraction, but that shouldn't block this series IMO. Other than patch: "[PATCH bpf-next v4 07/17] libbpf: Support drivers with non-combined channels" which I'd like to see a bit more discussion on, I'm OK with this series. I haven't been able to test it (no hardware "hint, hint"), but I know Jonathan has been running it. Thanks for working on this, Max! Björn
