Messages in this thread | | | Subject | Re: [PATCH net-next v2 07/10] net: dsa: lan9303: Added basic offloading of unicast traffic | From | Egil Hjelmeland <> | Date | Thu, 27 Jul 2017 16:07:01 +0200 |
| |
On 27. juli 2017 15:31, Andrew Lunn wrote: >>> I think you are over-simplifying here. Say i have a layer 2 VPN and i >>> bridge port 1 and the VPN? The software bridge still wants to do STP >>> on port 1, in order to solve loops. >>> >> >> Problem is that the mainline lan9303_separate_ports() does its >> work by setting port 1 & 2 in STP BLOCKING state (and port 0 in >> FORWARDING state). So my understanding is that it would break port >> separation if LAN9303_SWE_PORT_STATE is written while the driver >> is in the non-bridged state. > > If the hardware cannot do it, that is a different matter. But if the > hardware can do STP states per port, you should try to make use of it > here. >
The HW does STP states per port, but not per pair of port. I can set port 1 in learning, but I can not tell port 2 to ignore addresses learned on port 1. (Except by using VLAN).
Unless somebody can come up with an other way to implement the port separation, I think this is how it has to be. I suppose we don't want to break the port separation feature.
>> I thought the SW bridge would carry doing its STP work even if >> there is a port_stp_state_set method on a DSA port? > > It will, but it means you are dropping frames in software, adding > extra load to the CPU, reducing the available bandwidth for the other > port, etc. >
That is exactly the case with all traffic with the current mainline driver.
> Andrew >
Egil
| |