Re: [PATCH net-next v1 11/11] eth: fbnic: Support AF_XDP page pool zero copy

["Björn Töpel" <bjorn@kernel.org>]

Björn Töpel <bjorn@kernel.org> writes:

> Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
>
>> On Tue, Nov 10, 2026 at 11:20:32AM +0100, Björn Töpel wrote:
>
>>> @@ -538,6 +547,13 @@ static int fbnic_bpf(struct net_device *netdev, struct netdev_bpf *bpf)
>>>  {
>>>  	struct bpf_prog *prog = bpf->prog, *prev_prog;
>>>  	struct fbnic_net *fbn = netdev_priv(netdev);
>>> +	const struct xsk_rx_check *check;
>>> +
>>> +	if (bpf->command == XDP_VALIDATE_XSK_POOL) {
>>
>> do you really need a separate command here? why not rely on existing
>> XDP_SETUP_XSK_POOL ?
>>
>> here it doesn't look like things being validated are something unique that
>> you could not check during XDP_SETUP_XSK_POOL and XDP_SETUP_PROG.
>
> I'd like to keep it. XDP_SETUP_XSK_POOL means "set up driver ZC for this
> pool": the driver maps the UMEM and restarts its queue, and the core
> WARNs if it didn't map. A provider driver does neither; it only says yes
> or no, before the core maps and installs anything. The same question
> comes up on MTU and program changes of a bound device, with the new MTU
> or program, which XDP_SETUP_XSK_POOL can't carry. One command keeps that
> in one place, and v2 runs it from the core MTU path too, so a driver
> can't forget that case. This is only a burden for the core.

Thinking more about it, maybe I can drop the callback altogether, by
doing what devmem, io_uring zcrx and tcp-data-split already do: the core
refuses a setup that can't work, instead of asking the driver.

The driver only judges the chunk size and headroom, in
ndo_validate_qcfg, which the queue API already calls when it installs
the provider, with a new bit saying the buffers can't be split. A frame
of up to the chunk size (minus headroom), then lands in one buffer, so
the core checks the MTU itself, at bind and on MTU changes. And like
tcp-data-split, a socket bound with XDP_USE_SG needs a frags XDP
program: attaching a single-buffer program fails while one is bound, and
the bind fails while one is attached.

That drops XDP_VALIDATE_XSK_POOL and struct xsk_rx_check, and fbnic's
MTU and program hooks with them. Not fully cooked in my head, but maybe?
Wdyt?


Björn