On Mon, 5 Aug 2024 21:25:20 +0000 Mina Almasry wrote:
> + if (pool->p.queue) {
> + /* We rely on rtnl_lock()ing to make sure netdev_rx_queue
> + * configuration doesn't change while we're initializing the
> + * page_pool.
> + */
> + ASSERT_RTNL();
> + pool->mp_priv = pool->p.queue->mp_params.mp_priv;
How do you know that the driver:
- supports net_iov at all (let's not make implicit assumptions based
on presence of queue API);
- supports net_iov in current configuration (eg header-data split is
enabled)
- supports net_iov for _this_ pool (all drivers must have separate
buffer pools for headers and data for this to work, some will use
page pool for both)
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 if after queue reset
the refcount of the binding has increased. If it did - driver has
created a pool as we expected, otherwise - fail, something must be off.
Maybe that's a bit hacky?
