netdev - Re: RSTP with switchdev question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93982e05-e15b-7589-de38-ea64a87580fd@ti.com>
Date:   Thu, 19 Dec 2019 12:30:06 -0500
From:   Murali Karicheri <m-karicheri2@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>, "Kwok, WingMan" <w-kwok2@...com>,
        <vivien.didelot@...il.com>, <f.fainelli@...il.com>,
        <jiri@...nulli.us>, <ivecera@...hat.com>
Subject: Re: RSTP with switchdev question

Hi Andrew,

Thanks for responding to this.

On 12/17/2019 06:21 AM, Andrew Lunn wrote:
> On Mon, Dec 16, 2019 at 11:55:05AM -0500, Murali Karicheri wrote:
>> + switchdev/DSA experts
> 
> Hi Murali
> 
> I did not reply before because this is a pure switchdev issue. DSA
> does things differently. The kernel FDB and the switches FDB are not
> kept in sync. With DSA, when a port changes state, we flush the switch
> FDB. For STP, that seems to be sufficient. There have been reports for
> RSTP this might not be enough, but that conversation did not go very
> far.
I am new to RSTP and trying to understand what is required to be done
at the driver level when switchdev is used.

Looks like topology changes are handled currectly when only Linux bridge
is used and L2 forwarding is not offloaded to switch (Plain Ethernet
interface underneath).

This is my understanding. Linux bridge code uses BR_USER_STP to handle
user space  handling. So daemon manages the STP state machine and update
the STP  state to bridge which then get sent to device driver through
switchdev SET attribute command in the same way as kernel STP. From the
RSTP point of view, AFAIK, the quick data path switch over happens by
purging and re-learning when topology changes (TCN BPDUs). Currently
we are doing the following workaround which seems to solve the issue
based on the limited testing we had. Idea is for the switchdev based
switch driver to monitor the RTP state per port and if there is any
change in state, do a purge of learned MAC address in switch and send a
notification to bridge using
call_switchdev_notifiers(SWITCHDEV_FDB_DEL_TO_BRIDGE, dev, &info.info);

Following transition to be monitored and purged on any port:-
  Blocking   -> Learning  (assuming blocking to forward doesn't happen
                directly)
  Blocking   -> Forward (Not sure if this is possible. Need to check the
                spec.
  Learning   -> Blocked
  Forwarding -> Blocked

Hope the above are correct. Do you know if DSA is checking the above
transitions? Also when the learned address are purged in the switch
hardware, send event notification to Linux bridge to sync up with it's
database.

Since this is required for all of the Switchdev supported drivers,
it make sense to move this to switchdev eventually to trigger purge at
switch as well as notification to bridge for purge its entries. What do 
you think?

Regards,

Murali

> 
> I've no idea how this is supposed to work with a pure switchdev
> driver. Often, to answer a question like this, you need to take a step
> backwards. How is this supposed to work for a machine with two e1000e
> cards and a plain software bridge? What ever APIs user space RSTP is
> using in a pure software case should be used in a switchdev setup as
> well, but extra plumbing in the kernel might be required, and it
> sounds like it may be missing...
> 
>        Andrew
> 

-- 
Murali Karicheri
Texas Instruments