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!