Message-ID: <20220708120950.54ga22nvy3ge5lio@skbuf>
Date:   Fri, 8 Jul 2022 12:09:51 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Petr Machata <petrm@...dia.com>,
        Ido Schimmel <idosch@...dia.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Arun Ramadoss <arun.ramadoss@...rochip.com>,
        Hauke Mehrtens <hauke@...ke-m.de>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

On Fri, Jul 08, 2022 at 12:00:33PM +0200, Martin Blumenstingl wrote:
> That made me look at another selftest and indeed: most of the
> local_termination.sh tests are passing (albeit after having to make
> some changes to the selftest scripts, I'll provide patches for these
> soon)
> 
> None (zero) of the tests from bridge_vlan_unaware.sh and only a single
> test from bridge_vlan_aware.sh ("Externally learned FDB entry - ageing
> & roaming") are passing for me on GSWIP.
> Also most of the ethtool.sh tests are failing (ping always reports
> "Destination Host Unreachable").

I don't recall having run ethtool.sh, so I don't know what's the status
there.

> I guess most (or at least more) of these are supposed to pass? Do you
> want me to open another thread for this or is it fine to reply here?

So yes, the intention is for the selftests to pass, but I wouldn't be
surprised if they don't. They didn't when I started this effort for the
ocelot/felix DSA driver either, it's most likely that individual drivers
will need changes, that's kind of the whole point of having selftests,
to have implementations that are uniform in terms of behavior.
For the ocelot driver, the tests symlinked in the DSA folder do pass
(with the exception of the locked port test, which isn't implemented,
and the bridge local_termination.sh tests, but that's a bridge problem
and not a driver problem). I should have a remote setup and I should be
able to repeat some tests if necessary.

I think it would be a good idea to create a new email thread with the
relevant DSA maintainers for selftest status on GSWIP. You'll need to
gather some information on what exactly fails when things fail.
The way I prefer to do this is to run the test itself with "bash -x
./bridge_vlan_unaware.sh swp0 swp1 swp2 swp3", analyze a bit where
things get stuck, then edit the script, put a "bash" command after the
failing portion, and run the selftest again; this gives me a subshell
with all the VRFs configured from which I have more control and can
re-run the commands that just failed (I copy them from right above,
they're visible when run with bash -x). Then I try to manually check
counters, tcpdump, things like that.

> > I'm not familiar with OpenWrt, sorry, I don't know what netifd does.
> netifd is the network configuration daemon, it takes the network
> configuration (from OpenWrts configuration files/format) and sets up
> the corresponding interfaces and manages things like pppoe.

Thanks for the summary, I meant that I don't know what netifd does to
make loopback IP networking work in this case. Anyway it's not the
center point of the topic, as long as the interfaces used by the
kselftests are not managed by netifd or another network management
program.

> > > I'm thinking of packaging the selftests as OpenWrt package and also
> > > providing all needed dependencies as OpenWrt packages.
> > > I think (or I hope, not sure yet) the ping interval is just a matter
> > > of a busybox config option.
> >
> > I think it depends on busybox version. At least the latest one
> > https://github.com/mirror/busybox/blob/master/networking/ping.c#L970
> > seems to support fractions of a second as intervals, I didn't see any
> > restriction to sub-second values. In any case, the iputils version
> > certainly does work.
> Yes, there's a duration library inside busybox which by default only
> takes integer values (it can be configured to use floats though).
> I pushed my work in progress OpenWrt package to a branch, making use
> of the iputils version: [0]
> Compressed initramfs size is below 10M and uncompressed at 22M. My
> device under test has 128M of RAM and that seems to be enough to run
> mausezahn as well as any other tool that was run so far. So I am not
> particularly concerned about storage size (anything with 32M flash or
> more will do - 16M could be a bit tight in the end but will still work
> I guess).
> 
> 
> Best regards,
> Martin
> 
> 
> [0] https://github.com/xdarklight/openwrt-packages/commits/wip-kernel-selftests-net-forwarding-20220707

Sounds good then.

Powered by blists - more mailing lists