From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode Date: Wed, 6 Jun 2018 01:40:21 +0200 Message-ID: <20180605234021.GA6237@lunn.ch> References: <1527144984-31236-1-git-send-email-ilias.apalodimas@linaro.org> <20180524080528.GD2295@nanopsycho> <20180524084831.GA2759@apalos> <20180524125431.GB24557@lunn.ch> <7437d485-1eac-9619-3827-5af9b32b939e@redhat.com> <20180524140831.GA16793@apalos> <2b3cabca-4710-0a71-69c7-cc433e2b3062@ti.com> <20180603004937.GD14515@lunn.ch> <06981861-01aa-90c8-9b30-68426cbef447@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ilias Apalodimas , Ivan Vecera , Jiri Pirko , netdev@vger.kernel.org, ivan.khoronzhuk@linaro.org, nsekhar@ti.com, francois.ozog@linaro.org, yogeshs@ti.com, spatton@ti.com To: Grygorii Strashko Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:55585 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbeFEXkZ (ORCPT ); Tue, 5 Jun 2018 19:40:25 -0400 Content-Disposition: inline In-Reply-To: <06981861-01aa-90c8-9b30-68426cbef447@ti.com> Sender: netdev-owner@vger.kernel.org List-ID: > So, my understanding for (1) "blocked FDB entry support" is reasonable > extension for bridge/switchdev ("green"). You might have to justify it, but yes. > > Does the network stack need for forward specific multicast MAC > > addresses between bridge ports independent of the state? If there is > > no need for it, you don't need to accelerate it. > > Assume this is about item 2 - this question is related to STP packets. > CPSW/ALE will drop STP packets if receiving port is in blocking/learning states > unless corresponding mcast entry exist in ALE entry with (Supervisory Packet) flag set > (Actually ALE mcast entry has two fields (TRM): > Supervisory Packet (SUPER): When set, this field indicates that the packet > with a matching multicast destination address is a supervisory packet. > Multicast Forward State (MCAST_FWD_STATE): Indicates the port state(s) required for the received port > on a destination address lookup in order for the multicast packet to be forwarded to > the transmit port(s). A transmit port must be in the Forwarding state in > order to forward the packet.) So i this case, i would expect your driver to just add these entries to the ALE. No need for configuration for above. Just do it as soon as a port is made a member of a bridge. And remove it when the port leaves the bridge. DSA devices are smarter. They all have hardware which looks for BPDU and forwards them to the host independent of the state of the port. They also tend to have hardware looking for IGMP packets, and will forward them to the host, even if the multicast address is not being forwarded to the host. > ** "unknown vlan configuration" > > This is about following use case. Non static network configuration when > CPSW based device knows what traffic it can accept (Host port 0), but > it has no knowledge (or limited) about network segments attached to Port 1 and Port 2. > > For example: Host 0 can accept only vlan 100 traffic coming from Port 1. > ALE entry: vid =100, port_mask 0x3 > > But there can be vlan 50 created in attached network segments. > Unknown VLAN Force Untagged Egress ports Mask = 0x0 > Unknown VLAN Registered Multicast Flood Ports Mask = 0x6 (P1|P2) > Unknown VLAN Multicast Flood ports Mask = 0x6 (P1|P2) > Unknown VLAN Member ports List = 0x6 (P1|P2) > > with above configuration packets with "unknown vlan" (no ALE entry) will > still be forwarded between port 1 and 2, but not Port 0. > > So, is it reasonable to add "unknown vlan configuration" to bridge/switchdev > if not exist yet? will any other hw known benefit from it? You need to think about the case of two e1000e. How do you configure this setup to do what you want? It probably is already possible. Andrew