On Tue, 13 Aug 2024 16:11:15 +0100 Pavel Begunkov wrote: > On 8/13/24 15:39, Jakub Kicinski wrote: > > On Tue, 13 Aug 2024 03:31:13 +0100 Pavel Begunkov wrote: > >> I'm getting lost, so repeating myself a bit. What I think > >> would be a good approach is if we get an error back from > >> the driver if it doesn't support netiov / providers. > >> > >> netdev_rx_queue_restart() { > >> ... > >> err = dev->queue_mgmt_ops->ndo_queue_mem_alloc(); > >> if (err == -EOPNOTSUPP) // the driver doesn't support netiov > >> return -EOPNOTSUPP; > >> ... > >> } > >> > >> That can be done if drivers opt in to support providers, > >> e.g. via a page pool flag. > >> > >> What I think wouldn't be a great option is getting back a > >> "success" from the driver even though it ignored > > > > page pool params are not the right place for a supported flag. > > Sooner or later we'll want to expose this flag to user space. > > Fair enough, it appeared to me that's what you was suggesting > > "What comes to mind is adding an "I can gobble up net_iovs from this > pool" flag in page pool params (the struct that comes from the driver), > and then on the installation path we can check ..." Yes, we still need one flag in page pool params -- functioning like the inverse of PP_IGNORE_PROVIDERS, I'd call it something like PP_CAP_NET(MEM|IOV). To distinguish the header and data pools. > We can also move it from pp flags to queue API callbacks, however if we > want to expose it to the userspace, I'd imagine we need a queue flag set > by the driver, which then can be queried by netlink or whichever > interface is appropriate. And it can be used can be used to fail > netdev_rx_queue_restart() for queues/drivers that don't support mp. > > netdev_rx_queue_restart() { > if (rxq->mp_params && !rxq->netiov_supported) > fail; > } Yup!