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
on each offloaded packet as it is implied by BR_FLOOD_OFFLOAD bridge
port f
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 | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff
Allow to modify BR_FLOOD_OFFLOAD flag value through both sysfs and
netlink interface.
Signed-off-by: Igor Mitsyanko
---
include/uapi/linux/if_link.h | 1 +
net/bridge/br_netlink.c | 8 +++-
net/bridge/br_sysfs_if.c | 2 ++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git
Setting bridge flag BR_FLOOD_OFFLOAD only makes sense if underlying
port hardware advertises support for it. Make sure kernel checks that
condition before allowing to update the flag value.
Signed-off-by: Igor Mitsyanko
---
net/bridge/br_private.h | 5 -
1 file changed, 4 insertions(+), 1 de
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 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_
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 port,
it needs to be flooded to a single HW port of any given
switc
David Woodhouse wrote:
>
>
> On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
> >
> > > > I did performance measurements in the following way:
> > > >
> > > > Removed those pieces of the packet pipeline that I don't necessarily
> > > > need one-by-one. Then measured their effect on
On Fri, 2018-03-09 at 10:57 -0500, David Miller wrote:
> From: David Woodhouse
> Date: Fri, 09 Mar 2018 15:31:15 +
>
> > Eschewing a 15% speedup on the basis that "well, even though we've had
> > three of these already for a decade, we're worried that adding a fourth
> > might open the floo
From: David Woodhouse
Date: Fri, 09 Mar 2018 15:31:15 +
> Eschewing a 15% speedup on the basis that "well, even though we've had
> three of these already for a decade, we're worried that adding a fourth
> might open the floodgates to further patches" does seem a little odd to
> me, FWIW.
The
On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
>
> > > I did performance measurements in the following way:
> > >
> > > Removed those pieces of the packet pipeline that I don't necessarily
> > > need one-by-one. Then measured their effect on small packet
> > > performance.
> > >
>
10 matches
Mail list logo
