Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Jan 28, 2019 at 04:57:49PM +0100, Miquel Raynal wrote:
> Hi Andrew,
> 
> Thanks for helping!
> 
> Andrew Lunn <andrew@lunn.ch> wrote on Mon, 28 Jan 2019 15:44:17 +0100:
> 
> > > I don't see where VLAN and bridge information are cached, can you point
> > > me to the relevant locations?  
> > 
> > Miquèl
> > 
> > The bridge should have all that information. You need to ask it to
> > enumerate the current configuration and replay it to the switch.
> > 
> > There might be something in the Mellanox driver you can copy? But i've
> > not looked, i'm just guessing.
> 
> I am still searching but so far I did not find a mechanism reading the
> configuration of the bridge out of a 'net' object. Indeed there are
> multiple lists with the configuration but they are all 'mellanox'
> objects, they do not belong to the core.

Hi Miquèl

Look at how iproute2 works. How does the bridge command enumerate the
fdb and mdb's? How does bridge vlan show work? bridge link show? See
if you can use this infrastructure within the kernel.

> > We also need to think about how we are going to test this. There is a
> > lot of state information in a switch. So we are going to need some
> > pretty good tests to show we have recreated all of it.
> 
> My understanding of all this is rather short, until know I used what
> you proposed in the v1 of this series but I am all ears if I need to
> add anything to my test list.

What you probably need is a generic DSA test suite, with a number of
hardware devices, with different generations of mv88e6xxx devices, and
ideally different sf2, kzs, etc switches. Setup a configuration and
test is works correctly. Suspend, resume, and test is still works. And
you probably need to go through a number of cycles of suspend/resume.
And you are going to need to maintain that for a number of years,
testing every release, to see what breaks as we add new features and
new devices.

There also needs to be some though put into what happens when the
network changes while the switch is suspended. A port looses its link,
a port comes up, an SFP module is ejected, and SFP module is
inserted. The PTP grand master moves, etc. I hope the usual mechanisms
just work, but it all needs testing.

S2RAM is hard for a device like this. It is not something i personally
would want to do :-(

      Andrew