Re: [PATCH iproute2-next 0/6] bridge: vlan: add per-vlan options support

[David Ahern <dsahern@gmail.com>]

On 4/18/21 5:01 AM, Nikolay Aleksandrov wrote:
> From: Nikolay Aleksandrov <nikolay@nvidia.com>
> 
> Hi,
> This set extends the bridge vlan code to use the new vlan RTM calls
> which allow to dump detailed per-port, per-vlan information and also to
> manipulate the per-vlan options. It also allows to monitor any vlan
> changes (add/del/option change). The rtm vlan dumps have an extensible
> format which allows us to add new options and attributes easily, and
> also to request the kernel to filter on different vlan information when
> dumping. The new kernel dump code tries to use compressed vlan format as
> much as possible (it includes netlink attributes for vlan start and
> end) to reduce the number of generated messages and netlink traffic.
> The iproute2 support is activated by using the "-d" flag when showing
> vlan information, that will cause it to use the new rtm dump call and
> get all the detailed information, if "-s" is also specified it will dump
> per-vlan statistics as well. Obviously in that case the vlans cannot be
> compressed. To change per-vlan options (currently only STP state is
> supported) a new vlan command is added - "set". It can be used to set
> options of bridge or port vlans and vlan ranges can be used, all of the
> new vlan option code uses extack to show more understandable errors.
> The set adds the first supported per-vlan option - STP state.
> Man pages and usage information are updated accordingly.
> 
> Example:
>  $ bridge -d vlan show
>  port              vlan-id
>  ens13             1 PVID Egress Untagged
>                      state forwarding
>  bridge            1 PVID Egress Untagged
>                      state forwarding
> 
>  $ bridge vlan set vid 1 dev ens13 state blocking
>  $ bridge -d vlan show
>  port              vlan-id
>  ens13             1 PVID Egress Untagged
>                      state blocking
>  bridge            1 PVID Egress Untagged
>                      state forwarding
> 
> We plan to add many more per-vlan options in the future.
> 

applied. Thanks, Nik