lkml.org 
[lkml]   [2022]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH AUTOSEL 5.19 11/73] net: mscc: ocelot: adjust forwarding domain for CPU ports in a LAG
    Date
    On Sun, Oct 09, 2022 at 06:13:49PM -0400, Sasha Levin wrote:
    > From: Vladimir Oltean <vladimir.oltean@nxp.com>
    >
    > [ Upstream commit 291ac1517af58670740528466ccebe3caefb9093 ]
    >
    > Currently when we have 2 CPU ports configured for DSA tag_8021q mode and
    > we put them in a LAG, a PGID dump looks like this:
    >
    > PGID_SRC[0] = ports 4,
    > PGID_SRC[1] = ports 4,
    > PGID_SRC[2] = ports 4,
    > PGID_SRC[3] = ports 4,
    > PGID_SRC[4] = ports 0, 1, 2, 3, 4, 5,
    > PGID_SRC[5] = no ports
    >
    > (ports 0-3 are user ports, ports 4 and 5 are CPU ports)
    >
    > There are 2 problems with the configuration above:
    >
    > - user ports should enable forwarding towards both CPU ports, not just 4,
    > and the aggregation PGIDs should prune one CPU port or the other from
    > the destination port mask, based on a hash computed from packet headers.
    >
    > - CPU ports should not be allowed to forward towards themselves and also
    > not towards other ports in the same LAG as themselves
    >
    > The first problem requires fixing up the PGID_SRC of user ports, when
    > ocelot_port_assigned_dsa_8021q_cpu_mask() is called. We need to say that
    > when a user port is assigned to a tag_8021q CPU port and that port is in
    > a LAG, it should forward towards all ports in that LAG.
    >
    > The second problem requires fixing up the PGID_SRC of port 4, to remove
    > ports 4 and 5 (in a LAG) from the allowed destinations.
    >
    > After this change, the PGID source masks look as follows:
    >
    > PGID_SRC[0] = ports 4, 5,
    > PGID_SRC[1] = ports 4, 5,
    > PGID_SRC[2] = ports 4, 5,
    > PGID_SRC[3] = ports 4, 5,
    > PGID_SRC[4] = ports 0, 1, 2, 3,
    > PGID_SRC[5] = no ports
    >
    > Note that PGID_SRC[5] still looks weird (it should say "0, 1, 2, 3" just
    > like PGID_SRC[4] does), but I've tested forwarding through this CPU port
    > and it doesn't seem like anything is affected (it appears that PGID_SRC[4]
    > is being looked up on forwarding from the CPU, since both ports 4 and 5
    > have logical port ID 4). The reason why it looks weird is because
    > we've never called ocelot_port_assign_dsa_8021q_cpu() for any user port
    > towards port 5 (all user ports are assigned to port 4 which is in a LAG
    > with 5).
    >
    > Since things aren't broken, I'm willing to leave it like that for now
    > and just document the oddity.
    >
    > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    > Signed-off-by: Sasha Levin <sashal@kernel.org>
    > ---

    Not needed for stable kernels, please drop, thanks.
    \
     
     \ /
      Last update: 2022-10-10 13:59    [W:6.493 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site