mbox series

[v3,net-next,0/8] net: dsa: mv88e6xxx: Offload bridge port flags

Message ID 20210318192540.895062-1-tobias@waldekranz.com (mailing list archive)
Headers show
Series net: dsa: mv88e6xxx: Offload bridge port flags | expand

Message

Tobias Waldekranz March 18, 2021, 7:25 p.m. UTC
Add support for offloading learning and broadcast flooding flags. With
this in place, mv88e6xx supports offloading of all bridge port flags
that are currently supported by the bridge.

Broadcast flooding is somewhat awkward to control as there is no
per-port bit for this like there is for unknown unicast and unknown
multicast. Instead we have to update the ATU entry for the broadcast
address for all currently used FIDs.

v2 -> v3:
  - Only return a netdev from dsa_port_to_bridge_port if the port is
    currently bridged (Vladimir & Florian)

v1 -> v2:
  - Ensure that mv88e6xxx_vtu_get handles VID 0 (Vladimir)
  - Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir)
  - Fast age all entries on port when disabling learning (Vladimir)
  - Correctly detect bridge flags on LAG ports (Vladimir)

Tobias Waldekranz (8):
  net: dsa: Add helper to resolve bridge port from DSA port
  net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGs
  net: dsa: mv88e6xxx: Provide generic VTU iterator
  net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTU
  net: dsa: mv88e6xxx: Use standard helper for broadcast address
  net: dsa: mv88e6xxx: Flood all traffic classes on standalone ports
  net: dsa: mv88e6xxx: Offload bridge learning flag
  net: dsa: mv88e6xxx: Offload bridge broadcast flooding flag

 drivers/net/dsa/mv88e6xxx/chip.c | 270 ++++++++++++++++++++++---------
 drivers/net/dsa/mv88e6xxx/port.c |  21 +++
 drivers/net/dsa/mv88e6xxx/port.h |   2 +
 include/net/dsa.h                |  14 ++
 net/dsa/dsa_priv.h               |  14 +-
 5 files changed, 232 insertions(+), 89 deletions(-)

Comments

Tobias Waldekranz March 23, 2021, 10:45 a.m. UTC | #1
On Thu, Mar 18, 2021 at 20:25, Tobias Waldekranz <tobias@waldekranz.com> wrote:
> Add support for offloading learning and broadcast flooding flags. With
> this in place, mv88e6xx supports offloading of all bridge port flags
> that are currently supported by the bridge.
>
> Broadcast flooding is somewhat awkward to control as there is no
> per-port bit for this like there is for unknown unicast and unknown
> multicast. Instead we have to update the ATU entry for the broadcast
> address for all currently used FIDs.
>
> v2 -> v3:
>   - Only return a netdev from dsa_port_to_bridge_port if the port is
>     currently bridged (Vladimir & Florian)
>
> v1 -> v2:
>   - Ensure that mv88e6xxx_vtu_get handles VID 0 (Vladimir)
>   - Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir)
>   - Fast age all entries on port when disabling learning (Vladimir)
>   - Correctly detect bridge flags on LAG ports (Vladimir)
>
> Tobias Waldekranz (8):
>   net: dsa: Add helper to resolve bridge port from DSA port
>   net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGs
>   net: dsa: mv88e6xxx: Provide generic VTU iterator
>   net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTU
>   net: dsa: mv88e6xxx: Use standard helper for broadcast address
>   net: dsa: mv88e6xxx: Flood all traffic classes on standalone ports
>   net: dsa: mv88e6xxx: Offload bridge learning flag
>   net: dsa: mv88e6xxx: Offload bridge broadcast flooding flag
>
>  drivers/net/dsa/mv88e6xxx/chip.c | 270 ++++++++++++++++++++++---------
>  drivers/net/dsa/mv88e6xxx/port.c |  21 +++
>  drivers/net/dsa/mv88e6xxx/port.h |   2 +
>  include/net/dsa.h                |  14 ++
>  net/dsa/dsa_priv.h               |  14 +-
>  5 files changed, 232 insertions(+), 89 deletions(-)
>
> -- 
> 2.25.1

Jakub/Dave, is anything blocking this series from going in? I am unable
to find the series on patchwork, is that why?
Vladimir Oltean March 23, 2021, 10:52 a.m. UTC | #2
On Tue, Mar 23, 2021 at 11:45:03AM +0100, Tobias Waldekranz wrote:
> On Thu, Mar 18, 2021 at 20:25, Tobias Waldekranz <tobias@waldekranz.com> wrote:
> > Add support for offloading learning and broadcast flooding flags. With
> > this in place, mv88e6xx supports offloading of all bridge port flags
> > that are currently supported by the bridge.
> >
> > Broadcast flooding is somewhat awkward to control as there is no
> > per-port bit for this like there is for unknown unicast and unknown
> > multicast. Instead we have to update the ATU entry for the broadcast
> > address for all currently used FIDs.
> >
> > v2 -> v3:
> >   - Only return a netdev from dsa_port_to_bridge_port if the port is
> >     currently bridged (Vladimir & Florian)
> >
> > v1 -> v2:
> >   - Ensure that mv88e6xxx_vtu_get handles VID 0 (Vladimir)
> >   - Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir)
> >   - Fast age all entries on port when disabling learning (Vladimir)
> >   - Correctly detect bridge flags on LAG ports (Vladimir)
> >
> > Tobias Waldekranz (8):
> >   net: dsa: Add helper to resolve bridge port from DSA port
> >   net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGs
> >   net: dsa: mv88e6xxx: Provide generic VTU iterator
> >   net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTU
> >   net: dsa: mv88e6xxx: Use standard helper for broadcast address
> >   net: dsa: mv88e6xxx: Flood all traffic classes on standalone ports
> >   net: dsa: mv88e6xxx: Offload bridge learning flag
> >   net: dsa: mv88e6xxx: Offload bridge broadcast flooding flag
> >
> >  drivers/net/dsa/mv88e6xxx/chip.c | 270 ++++++++++++++++++++++---------
> >  drivers/net/dsa/mv88e6xxx/port.c |  21 +++
> >  drivers/net/dsa/mv88e6xxx/port.h |   2 +
> >  include/net/dsa.h                |  14 ++
> >  net/dsa/dsa_priv.h               |  14 +-
> >  5 files changed, 232 insertions(+), 89 deletions(-)
> >
> > -- 
> > 2.25.1
> 
> Jakub/Dave, is anything blocking this series from going in? I am unable
> to find the series on patchwork, is that why?

Tobias, the series went in:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d7417ee918582504076ec1a74dfcd5fe1f55696c

I'm not sure why the patchwork bot didn't go "deet-doot-dot, I am a bot"
on us.
Tobias Waldekranz March 23, 2021, 11:03 a.m. UTC | #3
On Tue, Mar 23, 2021 at 12:52, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Tue, Mar 23, 2021 at 11:45:03AM +0100, Tobias Waldekranz wrote:
>> On Thu, Mar 18, 2021 at 20:25, Tobias Waldekranz <tobias@waldekranz.com> wrote:
>> > Add support for offloading learning and broadcast flooding flags. With
>> > this in place, mv88e6xx supports offloading of all bridge port flags
>> > that are currently supported by the bridge.
>> >
>> > Broadcast flooding is somewhat awkward to control as there is no
>> > per-port bit for this like there is for unknown unicast and unknown
>> > multicast. Instead we have to update the ATU entry for the broadcast
>> > address for all currently used FIDs.
>> >
>> > v2 -> v3:
>> >   - Only return a netdev from dsa_port_to_bridge_port if the port is
>> >     currently bridged (Vladimir & Florian)
>> >
>> > v1 -> v2:
>> >   - Ensure that mv88e6xxx_vtu_get handles VID 0 (Vladimir)
>> >   - Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir)
>> >   - Fast age all entries on port when disabling learning (Vladimir)
>> >   - Correctly detect bridge flags on LAG ports (Vladimir)
>> >
>> > Tobias Waldekranz (8):
>> >   net: dsa: Add helper to resolve bridge port from DSA port
>> >   net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGs
>> >   net: dsa: mv88e6xxx: Provide generic VTU iterator
>> >   net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTU
>> >   net: dsa: mv88e6xxx: Use standard helper for broadcast address
>> >   net: dsa: mv88e6xxx: Flood all traffic classes on standalone ports
>> >   net: dsa: mv88e6xxx: Offload bridge learning flag
>> >   net: dsa: mv88e6xxx: Offload bridge broadcast flooding flag
>> >
>> >  drivers/net/dsa/mv88e6xxx/chip.c | 270 ++++++++++++++++++++++---------
>> >  drivers/net/dsa/mv88e6xxx/port.c |  21 +++
>> >  drivers/net/dsa/mv88e6xxx/port.h |   2 +
>> >  include/net/dsa.h                |  14 ++
>> >  net/dsa/dsa_priv.h               |  14 +-
>> >  5 files changed, 232 insertions(+), 89 deletions(-)
>> >
>> > -- 
>> > 2.25.1
>> 
>> Jakub/Dave, is anything blocking this series from going in? I am unable
>> to find the series on patchwork, is that why?
>
> Tobias, the series went in:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d7417ee918582504076ec1a74dfcd5fe1f55696c

Ahh, that explains that. I have been looking for it in the diffstat when
pulling net-next, but David pulled it in so fast that it probably flew
by before I expected it :)

> I'm not sure why the patchwork bot didn't go "deet-doot-dot, I am a bot"
> on us.

Yeah that is weird.

Thanks!