On Wed, Apr 29, 2026 at 02:08:31PM +0200, Daniel Borkmann wrote: > Hi Bobby, > > On 4/29/26 12:41 AM, Bobby Eshleman wrote: > > This series enables TCP devmem TX through netkit devices. > > > > Netkit now supports queue leasing. A physical NIC's RX queue can be > > leased to a netkit guest interface inside a container namespace. This > > gives the container a devmem-capable data path on the RX side (bind-rx, > > etc...). On the TX side, the container process binds to its netkit guest > > interface and sends traffic that netkit redirects (via BPF or ip > > forwarding) to the physical NIC for DMA. > [...] > Thanks for working on this, after the RX queue leasing got merged, I've > been looking into the same actually. :) > > I think the NETMEM_TX_* enum approach seems reasonable. > > What I have a PoC on is to build out TX queue leasing as first-class > symmetric infrastructure to complement the RX queue leasing - basically > I implemented an equivalent to the latter in netdev_nl_queue_create_doit > et al, so you can have independent RX and TX leases and per-queue > accountability, such that ynl queue-get op shows the full picture, and > lastly we could also enable AF_XDP TX-only support through this infra. > > Would you be open to collab on integrating both and migrating the devmem > code to work off an TX queue object? Next week is LSF/MM/BPF, are you > there by any chance to catch up in person? >
Hey Daniel, Definitely am open to that. I will unfortunately not be at LSF/MM/BPF, but maybe we can schedule a meeting offline to sync up? On the approach, explicit TX queue leasing sounds like a better way to permit devmem's tx binding than implicitly via RX lease. Best, Bobby
