From: Andrew Lunn <andrew@lunn.ch>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Ivan Vecera <ivecera@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
netdev@vger.kernel.org, ivan.khoronzhuk@linaro.org,
nsekhar@ti.com, francois.ozog@linaro.org, yogeshs@ti.com,
spatton@ti.com
Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode
Date: Sun, 3 Jun 2018 02:49:37 +0200 [thread overview]
Message-ID: <20180603004937.GD14515@lunn.ch> (raw)
In-Reply-To: <2b3cabca-4710-0a71-69c7-cc433e2b3062@ti.com>
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.
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.
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.
Andrew
next prev parent reply other threads:[~2018-06-03 0:49 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 6:56 [PATCH 0/4] RFC CPSW switchdev mode Ilias Apalodimas
2018-05-24 6:56 ` [PATCH 1/4] cpsw: move common headers definitions to cpsw_priv.h Ilias Apalodimas
2018-05-24 6:56 ` [PATCH 2/4] cpsw_ale: add support functions for switchdev Ilias Apalodimas
2018-05-24 6:56 ` [PATCH 3/4] cpsw_switchdev: add switchdev support files Ilias Apalodimas
2018-05-24 10:00 ` Maxim Uvarov
2018-05-27 4:39 ` kbuild test robot
2018-05-24 6:56 ` [PATCH 4/4] cpsw: add switchdev support Ilias Apalodimas
2018-05-24 13:12 ` Andrew Lunn
2018-05-24 13:32 ` Ilias Apalodimas
2018-05-24 16:39 ` Andrew Lunn
2018-05-25 4:56 ` Ilias Apalodimas
2018-06-01 21:48 ` Florian Fainelli
2018-06-02 10:34 ` Ilias Apalodimas
2018-06-02 16:10 ` Florian Fainelli
2018-06-02 16:52 ` Ilias Apalodimas
2018-06-05 21:03 ` Grygorii Strashko
2018-06-05 21:37 ` Florian Fainelli
2018-05-24 8:05 ` [PATCH 0/4] RFC CPSW switchdev mode Jiri Pirko
2018-05-24 8:48 ` Ilias Apalodimas
2018-05-24 12:54 ` Andrew Lunn
2018-05-24 13:44 ` Ivan Vecera
2018-05-24 14:08 ` Ilias Apalodimas
2018-05-24 14:54 ` Andrew Lunn
2018-05-24 15:07 ` Ilias Apalodimas
2018-05-24 15:25 ` Andrew Lunn
2018-05-24 16:02 ` Ilias Apalodimas
2018-05-24 16:33 ` Andrew Lunn
2018-05-25 6:29 ` Ilias Apalodimas
2018-05-25 10:28 ` Ilias Apalodimas
2018-05-25 11:59 ` Andrew Lunn
2018-05-25 12:09 ` Andrew Lunn
2018-05-31 15:27 ` Ilias Apalodimas
2018-06-02 23:28 ` Grygorii Strashko
2018-06-03 0:08 ` Andrew Lunn
2018-06-05 21:18 ` Grygorii Strashko
2018-06-05 21:28 ` Andrew Lunn
2018-06-05 21:42 ` Grygorii Strashko
2018-06-05 21:55 ` Andrew Lunn
2018-06-03 0:26 ` Andrew Lunn
2018-06-05 23:23 ` Grygorii Strashko
2018-06-05 23:49 ` Andrew Lunn
2018-06-06 8:23 ` Ivan Khoronzhuk
2018-06-03 0:37 ` Andrew Lunn
2018-06-05 21:31 ` Grygorii Strashko
2018-06-05 21:37 ` Andrew Lunn
2018-06-03 0:49 ` Andrew Lunn [this message]
2018-06-05 22:45 ` Grygorii Strashko
2018-06-05 23:40 ` Andrew Lunn
2018-06-01 21:29 ` Grygorii Strashko
2018-06-02 14:08 ` Andrew Lunn
2018-06-05 22:59 ` Grygorii Strashko
2018-06-05 23:53 ` Andrew Lunn
2018-06-06 6:42 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180603004937.GD14515@lunn.ch \
--to=andrew@lunn.ch \
--cc=francois.ozog@linaro.org \
--cc=grygorii.strashko@ti.com \
--cc=ilias.apalodimas@linaro.org \
--cc=ivan.khoronzhuk@linaro.org \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=spatton@ti.com \
--cc=yogeshs@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).