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

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

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.

> Overall, +400 lines for zc pp-based support...not sure what I was
> expecting and I know we need Tx side implementation.

fbnic had no AF_XDP at all. Of patch 11, about 120 lines are TX and 58
are docs; the rest is RX setup, refill and the checks. 08-10 add XDP
redirect, netmem heads and whole buffers to fbnic, which aren't
ZC-specific.

> However, I am wondering if better example for this change set would be the
> driver that already supports pp *and* carries the separate ZC data path
> (ekhm, see ice?). Then you could show case at least in diffstat how much
> less work is needed for AF_XDP support.

ice RX is on page pool through libeth, but ice has no queue API, and
libeth can't select a provider yet; that's also why ice can't do devmem
or io_uring zcrx. The provider has no unaligned mode either, which ice
supports. mlx5 or gve already have page pool RX, the queue API and their
own ZC path, so one of those would show the deletion with less
groundwork. I can do that as a follow-up.


Björn