lkml.org 
[lkml]   [2017]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH net-next v2 07/10] net: dsa: lan9303: Added basic offloading of unicast traffic
    From
    Date
    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

    \
     
     \ /
      Last update: 2017-07-27 16:07    [W:3.305 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site