Re: [RFC net-next 2/4] selftests: drv-net: tso: add helpers for double tunneling GSO

[Jakub Kicinski]

On Thu, 9 Apr 2026 15:35:21 +0800 Xu Du wrote:
> > > I want to test the gro-hint parameter functionality of the GENEVE tunnel,
> > > so I intend to use YNL for the testing. I am conducting the test between
> > > two machines using SSH type. I want to add the gro-hint parameter on
> > > both the local and remote nodes; however, I am unable to invoke class
> > > RtnlFamily on the remote node via SSH.  
> >
> > Oh. But that's not really what you're doing:
> >
> > +def ynlcli(family, args, json=None, ns=None, host=None):
> > +    if (KSFT_DIR / "kselftest-list.txt").exists():
> > +        cli = KSFT_DIR / "net/lib/ynl/pyynl/cli.py"
> > +        spec = KSFT_DIR / f"net/lib/specs/{family}.yaml"
> > +    else:
> > +        cli = KSRC / "tools/net/ynl/pyynl/cli.py"
> > +        spec = KSRC / f"Documentation/netlink/specs/{family}.yaml"
> > +    if not cli.exists():
> > +        raise FileNotFoundError(f"cli not found at {cli}")
> > +    args = f"--spec {spec} --no-schema {args}"
> > +    return tool(cli.as_posix(), args, json=json, ns=ns, host=host, shell=True)
> >
> > You're not deploying anything to the remote system.
> > Are you assuming that the remote system magically has the same
> > filesystem layout?
> >
> > You can use the ynl CLI but it has to be whatever version is on
> > the remote system. Just call ynl --family rt-link, don't dig
> > around for the spec paths etc.
> >  
> 
> In fact, I have tested this from two different locations. The first is in
> tools/testing/selftests/drivers/net/hw/ using python3 tso.py,
> which utilizes the specs located in Documentation/netlink/specs/.
> The second follows the testing methodology described in the
> README.rst of tools/testing/selftests/drivers/net/, which uses the specs
> in net/lib/specs/. Based on this, I include that different processes utilize
> different spec locations.
> I also referred to the implementation in net/lib/py/ynl.py, which employs
> a similar handling logic. Both using the source code repository and
> installing the package can meet the requirements for remote testing.

On the local system you have Python bindings.
On the remote system you can't assume KSFT_DIR or KSRC exist.

You can use ynl CLI on the remote system, like we use ip, tc etc.
But then just use --family rt-link, don't try to find the filesystem
path to the spec.

Is this clear now? Am I misunderstanding your misunderstanding?