to forward the frame to wlan0.
When passing a frame upwards, clear the flag. This is the Rx
equivalent of br_switchdev_frame_unmark() in br_dev_xmit().
Fixes: f1c2eddf4cb6 ("bridge: switchdev: Use an helper to clear forward mark")
Signed-off-by: Andrew Lunn
---
v2:
Extended the commit mes
> I like Andrew's patch because it is the Rx equivalent of
> br_switchdev_frame_unmark() in br_dev_xmit(). However, if we go with the
> second option, it should allow us to remove the clearing of the mark in
> the Tx path as the control block is cleared in the Tx path since commit
> fd65e5a95d08 ("
> Some safer alternatives to this patch are based on the idea that we
> could ignore skb->offload_fwd_mark coming from an unoffloaded bridge
> port (i.e. treat this condition at br1, not at br0). We could:
> - clear skb->offload_fwd_mark in br_handle_frame_finish(), if p->hwdom is 0
> - change nbp_
On Thu, May 05, 2022 at 04:07:20PM -0700, Stephen Hemminger wrote:
> On Fri, 6 May 2022 00:59:04 +0200
> Andrew Lunn wrote:
>
> > It is possible to stack bridges on top of each other. Consider the
> > following which makes use of an Ethernet switch
lper to clear forward mark")
Signed-off-by: Andrew Lunn
---
net/bridge/br_input.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 196417859c4a..9327a5fad1df 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -39,6 +3
On Thu, Mar 17, 2022 at 09:52:15AM +0100, Hans Schultz wrote:
> On tor, mar 17, 2022 at 01:34, Vladimir Oltean wrote:
> > On Mon, Mar 14, 2022 at 11:46:51AM +0100, Hans Schultz wrote:
> >> >> @@ -396,6 +414,13 @@ static irqreturn_t
> >> >> mv88e6xxx_g1_atu_prob_irq_thread_fn(int irq, void *dev_id
> + if (mv88e6xxx_port_is_locked(chip, chip->ports[spid].port))
> + err =
> mv88e6xxx_switchdev_handle_atu_miss_violation(chip,
> +
> chip->ports[spid].port,
> +
> > + if (p->flags & BR_PORT_LOCKED) {
> > + fdb_entry = br_fdb_find_rcu(br, eth_hdr(skb)->h_source, vid);
> > + if (!(fdb_entry && fdb_entry->dst == p))
> > + goto drop;
>
> I'm not familiar with 802.1X so I have some questions:
Me neither.
>
> 1. Do we
On Mon, Jul 26, 2021 at 07:21:20PM +0530, Naresh Kamboju wrote:
> On Wed, 21 Jul 2021 at 21:56, Vladimir Oltean wrote:
> >
> > On reception of an skb, the bridge checks if it was marked as 'already
> > forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it
> > is, it assigns the
> There is really no need to recompute the static parts of the tags on
> each skb. It would mean moving some knowledge of the tagging format to
> the driver. But that boundary is pretty artificial for
> mv88e6xxx. tag_dsa has no use outside of mv88e6xxx, and mv88e6xxx does
> not work with any other
On Tue, Jan 19, 2021 at 09:32:40AM +0100, Horatiu Vultur wrote:
> The 01/18/2021 21:27, Vladimir Oltean wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Mon, Jan 18, 2021 at 09:20:36PM +0100, Horatiu Vultur wrote:
> > > The 01/18
e switch.
>
> This patch addresses the issue by monitoring the addresses learnt by the
> software bridge on eno0, and adding/deleting them as static FDB entries
> on the CPU port accordingly.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Sun, Dec 13, 2020 at 04:07:09PM +0200, Vladimir Oltean wrote:
> Some DSA switches (and not only) cannot learn source MAC addresses from
> packets injected from the CPU. They only perform hardware address
> learning from inbound traffic.
Reviewed-by: Andrew Lunn
Andrew
dev_work) is not called.
>
> We can avoid scheduling the worker for nothing and say NOTIFY_DONE.
> Because we don't call dsa_fdb_offload_notify, the static FDB entry will
> remain just in the software bridge.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
the error message, and drop dev_close().
>
> Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Andrew
the bridge's FDB.
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 22, 2020 at 02:01:28PM +0800, Chuanhong Guo wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 12:36 AM Andrew Lunn wrote:
> >
> > The MAC address needs to move, no argument there. But what are the
> > mechanisms which cause this. Is learning sufficient, or does DSA
> When a client moves from a hardware port (e.g. sw0p1) to a software port
> (wlan0)
> or another hardware port that belongs to a different switch (sw1p1),
> that MAC entry
> in sw0's MAC table should be deleted, or replaced with the CPU port as
> destination,
> by DSA. Otherwise the client is una
gfang
> ---
> I tried this on mt7530 and mv88e6xxx, but only mt7530 works.
> In previous discussion[1], Andrew Lunn said "try playing with auto learning
> for the CPU port" but it didn't work on mv88e6xxx either
Hi Deng
We should probably first define how we expect moving
On Mon, Jan 27, 2020 at 03:26:38PM +0100, Jürgen Lambrecht wrote:
> On 1/27/20 12:04 PM, Allan W. Nielsen wrote:
>
> > How do you handle the 'headless chicken' scenario? User space
> tells
> > the port to start sending MRP_Test frames. It then dies. The
>
> > 'Thinking allowed' here.
> >
> > +--+
> > | |
> > +-->|H1|<-->|H2|<-->|H3|<--+
> > eth0eth1eth0eth1eth0eth1
> > ^
> > |
> > Blocked
> >
> >
> > The
On Sun, Jan 26, 2020 at 02:01:11PM +0100, Horatiu Vultur wrote:
> The 01/25/2020 17:16, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > > br_netif_receive_skb(struct net *net, s
On Sun, Jan 26, 2020 at 02:22:13PM +0100, Horatiu Vultur wrote:
> The 01/25/2020 17:35, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > > SWITCHDEV_OBJ_ID_RING_TEST_MRP: This is u
> We could do also that. The main reason why I have added a new generic
> netlink was that I thought it would be clearer what commands are for MRP
> configuration.
The naming makes this clear, having _MRP_ in the attribute names etc.
But it would be good have input from the Bridge maintainers.
> SWITCHDEV_OBJ_ID_RING_TEST_MRP: This is used when to start/stop sending
> MRP_Test frames on the mrp ring ports. This is called only on nodes that
> have
> the role Media Redundancy Manager.
How do you handle the 'headless chicken' scenario? User space tells
the port to start sending MRP_Te
> Lets say that the link between H1 and H2 goes down:
>
> +--+
> | |
> +-->|H1|<--- / --->|H2|<-->|H3|<--+
> eth0eth1eth0eth1eth0eth1
>
> H1 will now observe that the test
> br_netif_receive_skb(struct net *net, struct sock *sk, struct sk_buff *skb)
> @@ -338,6 +341,17 @@ rx_handler_result_t br_handle_frame(struct sk_buff
> **pskb)
> return RX_HANDLER_CONSUMED;
> }
> }
> +#ifdef CONFIG_BRIDGE_MRP
> + /* If there is no M
On Sat, Jan 25, 2020 at 12:37:26PM +0100, Horatiu Vultur wrote:
> The 01/24/2020 18:43, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > > br_mrp_flush - will flush the FDB.
> >
&g
On Fri, Jan 24, 2020 at 05:18:27PM +0100, Horatiu Vultur wrote:
> To integrate MRP into the bridge, the bridge needs to do the following:
> - initialized and destroy the generic netlink used by MRP
> - detect if the MRP frame was received on a port that is part of a MRP ring.
> In
> case it was
On Fri, Jan 24, 2020 at 05:18:22PM +0100, Horatiu Vultur wrote:
> Implement the generic netlink interface to configure MRP. The implementation
> will do sanity checks over the attributes and then eventually call the MRP
> interface which eventually will call the switchdev API.
Hi Horatiu
What was
> br_mrp_flush - will flush the FDB.
How does this differ from a normal bridge flush? I assume there is a
way for user space to flush the bridge FDB.
Andrew
On Fri, Jan 24, 2020 at 05:18:20PM +0100, Horatiu Vultur wrote:
> In case the HW is capable to detect when the MRP ring is open or closed. It is
> expected that the network driver will notify the bridge that the ring is open
> or
> closed.
>
> The function br_mrp_port_open is used to notify the k
On Tue, Jan 14, 2020 at 09:08:56AM +0100, Horatiu Vultur wrote:
> The 01/14/2020 00:30, Andrew Lunn wrote:
> >
> > Hi Horatiu
> >
> > It has been said a few times what the basic state machine should be in
> > user space. A pure software solution can use ra
Hi Horatiu
It has been said a few times what the basic state machine should be in
user space. A pure software solution can use raw sockets to send and
receive MRP_Test test frames. When considering hardware acceleration,
the switchdev API you have proposed here seems quite simple. It should
not be
On Mon, Jan 13, 2020 at 01:46:20PM +0100, Horatiu Vultur wrote:
> +#ifdef CONFIG_BRIDGE_MRP
> +/* SWITCHDEV_OBJ_ID_PORT_MRP */
> +struct switchdev_obj_port_mrp {
> + struct switchdev_obj obj;
> + struct net_device *port;
> + u32 ring_nr;
> +};
> +
> +#define SWITCHDEV_OBJ_PORT_MRP(OBJ)
On Fri, Jan 10, 2020 at 09:12:48PM +0100, Horatiu Vultur wrote:
> The 01/10/2020 18:56, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > > > Horatiu, could you also give some r
> > Horatiu, could you also give some references to the frames that need
> > to be sent. I've no idea what information they need to contain, if the
> > contents is dynamic, or static, etc.
> It is dynamic - but trivial...
If it is trivial, i don't see why you are so worried about abstracting
it?
> I think it would help your case if you explained a bit more about
> the hw offload primitives you have implemented internally.
Agreed.
Horatiu, could you also give some references to the frames that need
to be sent. I've no idea what information they need to contain, if the
contents is dynamic,
> That sounds like a great idea. I was expecting to add this logic in the
> set_rx_mode function of the driver. But unfortunetly, I got the calls to
> this function before the dev->promiscuity is updated or not to get the
> call at all. For example in case the port is member of a bridge and I try
>
On Mon, Aug 26, 2019 at 10:11:12AM +0200, Horatiu Vultur wrote:
> When a network port is added to a bridge then the port is added in
> promisc mode. Some HW that has bridge capabilities(can learn, forward,
> flood etc the frames) they are disabling promisc mode in the network
> driver when the port
> > > Why do the devices have to be from the same driver ?
> After seeing yours and Andrews comments I realize that I try to do two
> things, but I have only explained one of them.
>
> Here is what I was trying to do:
> A. Prevent ports from going into promisc mode, if it is not needed.
The switc
> +/* Determin if the SW bridge can be offloaded to HW. Return true if all
> + * the interfaces of the bridge have the feature NETIF_F_HW_SWITCHDEV set
> + * and have the same netdev_ops.
> + */
Hi Horatiu
Why do you need these restrictions. The HW bridge should be able to
learn that a destinatio
> > 2) The interface is part of a bridge. There are a few sub-cases
> >
> > a) IGMP snooping is being performed. We can block multicast where
> > there is no interest in the group. But this is limited to IP
> > multicast.
> Agree. And this is done today by installing an explicit offload rule to li
> Our plan was to implement this in pure SW, and then look at how to HW offload
> it.
Great.
> But this will take some time before we have anything meaning full to show.
>
> > Make it an alternative to the STP code?
> I'm still working on learning the details of DLR, but I actually believe that
Hi Allan
Just throwing out another idea
The whole offloading story has been you use the hardware to accelerate
what the Linux stack can already do.
In this case, you want to accelerate Device Level Ring, DLR. But i've
not yet seen a software implementation of DLR. Should we really be
consid
> Trying to get back to the original problem:
>
> We have a network which implements the ODVA/DLR ring protocol. This protocol
> sends out a beacon frame as often as every 3 us (as far as I recall, default I
> believe is 400 us) to this MAC address: 01:21:6C:00:00:01.
>
> Try take a quick look at
> As you properly guessed, this model is quite different from what we are used
> to.
Yes, it takes a while to get the idea that the hardware is just an
accelerator for what the Linux stack can already do. And if the switch
cannot do some feature, pass the frame to Linux so it can handle it.
You
On Fri, Jul 26, 2019 at 02:02:15PM +0200, Horatiu Vultur wrote:
> Hi Nikolay,
>
> The 07/26/2019 12:26, Nikolay Aleksandrov wrote:
> > External E-Mail
> >
> >
> > On 26/07/2019 11:41, Nikolay Aleksandrov wrote:
> > > On 25/07/2019 17:21, Horatiu Vultur wrote:
> > >> Hi Nikolay,
> > >>
> > >> The
Hi Nikolay
The man page says that the bridge forward_delay is in units of
seconds, and should be between 2 and 30.
I've tested on a couple of different kernel versions, and this appears
to be not working correctly:
ip link set br0 type bridge forward_delay 2
RTNETLINK answers: Numerical result o
> Hi Andrew,
> The man page is wrong, these have been in USER_HZ scaled clock_t format from
> the beginning.
> TBH a lot of the time/delay bridge config options are messed up like that.
Hi Nikola
Yes, that is a mess.
arch/alpha/include/asm/param.h:# define USER_HZ
> > +IGMP snooping
> > +~
> > +
> > +The Linux bridge allows the configuration of IGMP snooping (compile and run
> > +time) which must be observed by the underlying switchdev network
> > device/hardware
> > +in the following way:
> > +
> > +- when IGMP snooping is turned off, multicast
> +VLAN filtering
> +~~
> +
> +The Linux bridge allows the configuration of a VLAN filtering mode (compile
> and
> +run time) which must be observed by the underlying switchdev network
> +device/hardware:
> +
> +- with VLAN filtering turned off: frames ingressing the device with a VID
so if an option desires
> it could set it on error and be more user-friendly.
>
> [1] https://www.spinics.net/lists/netdev/msg532698.html
>
> Signed-off-by: Nikolay Aleksandrov
Reviewed-by: Andrew Lunn
Andrew
flag that is tested before learning.
>
> v2: pass NULL for extack via sysfs
>
> Signed-off-by: Nikolay Aleksandrov
Reviewed-by: Andrew Lunn
Andrew
On Sat, Nov 24, 2018 at 04:34:22AM +0200, Nikolay Aleksandrov wrote:
> Now that we have at least one bool option, we can export all of the
> supported bool options via optmask when dumping them.
>
> v2: new patch
>
> Signed-off-by: Nikolay Aleksandrov
Reviewed-by: Andrew Lunn
Andrew
On Sat, Nov 24, 2018 at 06:18:33PM +0200, niko...@cumulusnetworks.com wrote:
> On 24 November 2018 18:10:41 EET, Andrew Lunn wrote:
> >> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id opt,
> >bool on,
> >> +struct netlink_ext_ack *ext
On Sat, Nov 24, 2018 at 04:34:22AM +0200, Nikolay Aleksandrov wrote:
> Now that we have at least one bool option, we can export all of the
> supported bool options via optmask when dumping them.
>
Hi Nik
That answers my question then...
I'm assuming this means there is no easy way to generate a
> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id opt, bool on,
> + struct netlink_ext_ack *extack)
> +{
> + switch (opt) {
> + default:
> + /* shouldn't be called with unsupported options */
> + WARN_ON(1);
> + break;
> int br_boolopt_get(const struct net_bridge *br, enum br_boolopt_id opt)
> {
> - int optval = 0;
> -
> switch (opt) {
> + case BR_BOOLOPT_NO_LL_LEARN:
> + return br_opt_get(br, BROPT_NO_LL_LEARN);
> default:
> break;
> }
>
> - return optv
> +void br_boolopt_multi_get(const struct net_bridge *br,
> + struct br_boolopt_multi *bm)
> +{
> + u32 optval = 0;
> + int opt_id;
> +
> + for (opt_id = 0; opt_id < BR_BOOLOPT_MAX; opt_id++)
> + optval |= (br_boolopt_get(br, opt_id) << opt_id);
> +
> +
> +/* br_boolopt_toggle - change user-controlled boolean option
> + *
> + * @br: bridge device
> + * @opt: id of the option to change
> + * @on: new option value
> + *
> + * Changes the value of the respective boolean option to @on taking care of
> + * any internal option value mapping and configur
On Thu, Nov 22, 2018 at 06:29:24AM +0200, Nikolay Aleksandrov wrote:
> We have been adding many new bridge options, a big number of which are
> boolean but still take up netlink attribute ids and waste space in the skb.
> Recently we discussed learning from link-local packets[1] and decided
> yet a
On Wed, Sep 26, 2018 at 05:55:47PM +0300, Nikolay Aleksandrov wrote:
> On 26/09/18 17:48, Andrew Lunn wrote:
> > Hi Nikolay
> >
> >> struct net_bridge {
> >>spinlock_t lock;
> >>spinlock_t
Hi Nikolay
> struct net_bridge {
> spinlock_t lock;
> spinlock_t hash_lock;
> struct list_headport_list;
> struct net_device *dev;
> struct pcpu_sw_netstats __percpu *stats;
> + unsig
On Sat, Mar 31, 2018 at 12:05:17AM -0700, Joe Perches wrote:
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> @@ -1,4 +1,4 @@
> -/*
> +gg/*
Hi Joe
This does not look good.
Andrew
> The flag was introduced to enable hardware switch capabilities of
> drivers/net/wireless/quantenna/qtnfmac wifi driver. It does not have any
> switchdev functionality in upstream tree at this moment, and this patchset
> was intended as a preparatory change.
O.K. But i suggest you add basic switc
On Fri, Mar 09, 2018 at 07:03:03PM -0800, Igor Mitsyanko wrote:
> Main goal of the patchset is to allow for flooding offload to switchdev
> in scenarios when HW switchdev ports and SW ports are operating in a
> single bridge.
>
> In case a data frame that needs to be flooded is ingressed on a SW p
On Fri, Mar 09, 2018 at 07:03:04PM -0800, Igor Mitsyanko wrote:
> Default bridge port flags for switchdev devices can be different from
> what is used in bridging core. Get default value from switchdev itself
> on port initialization.
>
> Signed-off-by: Igor Mitsyanko
> ---
> net/bridge/br_if.c
On Fri, Mar 09, 2018 at 07:03:06PM -0800, Igor Mitsyanko wrote:
> Introduce BR_FLOOD_OFFLOAD bridge port flag that can be used by
> switchdev-capable hardware to advertize that it wants to handle all
> flooding by itself.
> In that case there is no need for a driver to set skb::offload_fwd_mark
> o
On Fri, Mar 09, 2018 at 07:03:05PM -0800, Igor Mitsyanko wrote:
> sysfs interface to configure bridge flags only updates SW copy but does
> not notify hardware through switchdev interface. Make sure it is.
>
> Signed-off-by: Igor Mitsyanko
> ---
> net/bridge/br_sysfs_if.c | 15 +++
>
dr instead of eth_reserved_addr_base in br_dev_setup.
>
> Signed-off-by: Egil Hjelmeland
I was thinking along the same lines when reviewing your lan9303 patch.
Reviewed-by: Andrew Lunn
Andrew
On Mon, Aug 28, 2017 at 09:22:48PM -0700, Roopa Prabhu wrote:
> From: Roopa Prabhu
>
> A few useful tracepoints to trace bridge forwarding
> database updates.
Hi Roopa
Once accepted, it would be nice to add mdb tracepoints as well. I
expect the implementation would be very similar.
Andr
On Sun, Aug 27, 2017 at 07:44:15PM -0700, Florian Fainelli wrote:
> Hi Andrew,
>
> On 08/26/2017 01:56 PM, Andrew Lunn wrote:
> > This is a WIP patchset i would like comments on from bridge,
> > switchdev and hardware offload people.
> >
> > The linux bridg
> Hi Andrew,
>
> Have you taken a look at mglist (the boolean, probably needs a rename) ? It
> is for
> exactly that purpose, to track which groups the bridge is interested in.
> I assume I'm forgetting or missing something here.
>
> > performed. With a pure software bridge, it is not required.
When there is a mdb added to a port which is not in the switch, we
need the switch to forward traffic for the group to the software
bridge, so it can forward it out the none-switch port.
The current implementation is a hack and will be replaced. Currently
only the bridge soft interface is supporte
In order to perform IGMP snooping on the brX interface, it has to be
part of the bridge, so that the code snooping on normal bridge ports
keeps track of IGMP joins and leaves.
When the brX interface is opened, add the interface to the bridge.
When the brX interface is closed, remove it from the br
The brX interface will soon become a member of the bridge. As such, it
will get a receiver handler assigned. However, we don't want to handle
packets received on this soft interfaces. So detect the condition and
say all the packets pass.
---
net/bridge/br_input.c | 4
1 file changed, 4 insert
. what we are looking for.
Signed-off-by: Andrew Lunn
---
net/core/rtnetlink.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 9201e3621351..2673eb430b6f 100644
--- a/net/core/rtnetlink.c
+++ b/net/core
Now that the MDB are explicitly added to the CPU port when required,
don't add the CPU port adding an MDB to a switch port.
Signed-off-by: Andrew Lunn
---
net/dsa/switch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 97e2e9c
can be solved once it is agreed how the bridge needs to change to
support this use case.
Comment welcome and wanted.
Andrew
Andrew Lunn (5):
net: rtnetlink: Handle bridge port without upper device
net: bridge: Skip receive handler on brX interface
net: bridge: Make the brX interface a
80 matches
Mail list logo
