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

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

On Fri, Nov 13, 2026 at 12:40:09PM +0100, Björn Töpel wrote:
> 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?

Would be nice, what I meant mostly was that a single driver can't do both
'legacy' ZC and new-age provider based xsk at the same time, so let us
have a single vehicle down to drivers, adjusted to both needs?

> 
> 
> Björn
>