On Thu, Aug 10, 2023 at 9:09 AM Samudrala, Sridhar <sridhar.samudrala@xxxxxxxxx> wrote: > > > > On 8/9/2023 6:57 PM, Mina Almasry wrote: > > API takes the dma-buf fd as input, and binds it to the netdevice. The > > user can specify the rx queue to bind the dma-buf to. The user should be > > able to bind the same dma-buf to multiple queues, but that is left as > > a (minor) TODO in this iteration. > > To support binding dma-buf fd to multiple queues, can we extend/change > this interface to bind dma-buf fd to a napi_id? Amritha is currently > working on a patchset that exposes napi_id's and their association with > the queues. > > https://lore.kernel.org/netdev/169059098829.3736.381753570945338022.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx/ > Thank you Sridhar, I think honestly implementing multiple rx queue binding is trivial, even without the napi_id association. The user should be able to call the bind-rx API multiple times with the same dma-buf to bind to multiple queues, or I can convert the queue-idx to a multi-attr netlink attribute to let the user specify multiple rx queues in 1 call. Without doing some homework it's not immediately obvious to me that coupling the dma-buf binding with the napi_id is necessary or advantageous. Is there a reason coupling those is better? It seems like napi_id can also refer to TX queues, and binding a dma-buf with a TX queue doesn't make much sense to me. For TX we need to couple the dma-buf with the netdev that's sending the dma-buf data, but not a specific TX queue on the netdev, I think. -- Thanks, Mina
