From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grygorii Strashko Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode Date: Tue, 5 Jun 2018 17:45:49 -0500 Message-ID: <06981861-01aa-90c8-9b30-68426cbef447@ti.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: Ilias Apalodimas , Ivan Vecera , Jiri Pirko , , , , , , To: Andrew Lunn Return-path: Received: from fllnx210.ext.ti.com ([198.47.19.17]:11961 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbeFEWqC (ORCPT ); Tue, 5 Jun 2018 18:46:02 -0400 In-Reply-To: <20180603004937.GD14515@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: Hi Andrew, Thanks a lot for you comments. On 06/02/2018 07:49 PM, Andrew Lunn wrote: > Hi Grygorii > >> Don't know howto: >> 1) add FDB entry with "blocked" flag - ALE can discard all packets with SRC/DST >> address = blocked MAC >> 2) add multicast MAC address with Supervisory Packet flag set. >> Such packets will bypass most of checks inside ALE and will be forwarded in all port's >> states except "disabled". >> 3) add "unknown vlan configuration" : ALE provides possibility to configure >> default behavior for tagged packets with "unknown vlan" by configuring >> - Unknown VLAN Force Untagged Egress ports Mask. >> - Unknown VLAN Registered Multicast Flood Ports Mask >> - Unknown VLAN Multicast Flood ports Mask >> - Unknown VLAN Member ports List >> 4) The way to detect "brctl stp br0 on/off" > > You are probably looking at this from the wrong direction. Yes, the > switch can do these things. But the real question is, why would the > network stack want to do this? As i've said before, you are > accelerating the network stack by offloading things to the hardware. Right. Thanks. > > Does the software bridge support FDB with a blocked flag? I don't > think it does. So you first need to extend the software bridge with > this concept. Then you can offload it to the hardware to accelerate > it. Sry, for possible misunderstanding: in "Don't know howto" i've listed things I was not able to discover from code or documentation with hope that expert opinion will help to confirm if this this a real/possible gap or I/we've just missed smth. And if this is a real gap - get "green" or "red" flag for future work (which need to be planned somehow). So, my understanding for (1) "blocked FDB entry support" is reasonable extension for bridge/switchdev ("green"). > > 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.) Question 4 was asked with assumption that if (2) not supported and "red" flag - then option (4) can be used as w/a (again if "green" flag) and STP mcast address can be added in ALE on event "stp on". ** "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? -- regards, -grygorii