Re: [PATCH v3 net-next 11/15] selftests: xsk: add a hardware mode to xskxceiver

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

On Thu, Oct 15, 2026 at 11:42:51AM +0200, Björn Töpel wrote:
> Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
> 
> > drivers/net/hw/xsk.py, added later in this series, runs each hardware
> > AF_XDP case as a zero-copy DUT endpoint and an SKB-mode remote endpoint
> > over a physical link, without negotiating capabilities between them.
> > Add what such a run needs to xskxceiver:
> >
> > - --hw sends UDP/IPv4 test packets (--udp-src, --udp-dst, --udp-port)
> >   between the real interface MACs (--peer-mac); XDP_SHARED_UMEM, whose
> >   program picks the socket by a synthetic destination MAC, skips
> 
> This reads weird to me.
> 
> I wonder if we can avoid introducing a separate "hardware" mode here? It
> seems to bundle packet format, link handling, and assumptions about the
> endpoint modes. Those are separate concerns, and much of this should
> work with veth too, no?
> 
> Could we first make the real MAC addresses and IPv4/UDP format common to
> both veth and physical-device runs?

I must admit I have not tried that and --hw introduction feels like veth
approach is still a first-class citizen here. Aligning both test runners
would simplify stuff I assume, will look at it.

> 
> Then --listen could work independently, timeouts could be configurable,
> and test selection could reflect the actual endpoint modes and
> capabilities.

You select cases based on DUT's endpoint and its capabilities. Regarding
timeouts, we can add a knob for it, sure.

> For example, skipping TX_QUEUE_CONSUMER because hw_test
> implies mixed ZC/SKB endpoints seems to encode the launcher's current
> configuration into the test itself. "Real" endpoints could also run the
> same mode.

This test has nothing to do with ZC at all, Jason added this during one of
the many xsk_generic_xmit() bugfixes.

https://lore.kernel.org/bpf/20250703141712.33190-3-kerneljasonxing@gmail.com/

Remote endpoint's role is rather limited and I wanted to be sure that we
cover both tx and rx sides from particular test cases, that's the purpose
behind --direction and storing test cases within 'hw_group's.

> 
> If we need to keep both packet formats, something like
> --packet-format=udp would maybe describe it better. I'd prefer keeping
> these behaviors independent rather than giving the combined mode another
> name.

Nah, let's make veth runner use what currently 'hw' side does.

> 
> Also, we need IPv6 support here in addition to IPv4. You can't assume
> that the DUT is onlink or IPv4.

Is that currently a show-stopper? That is another left-over from old
architecture where data path was rather on a local and isolated
environment... /me finding excuses ;)

> 
> 
> Björn