[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200114175614.17543-1-nikolay@cumulusnetworks.com>
Date: Tue, 14 Jan 2020 19:56:06 +0200
From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To: netdev@...r.kernel.org
Cc: roopa@...ulusnetworks.com, davem@...emloft.net, kuba@...nel.org,
bridge@...ts.linux-foundation.org, dsahern@...il.com,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: [PATCH net-next v2 0/8] net: bridge: add vlan notifications and rtm support
Hi,
This patch-set is a prerequisite for adding per-vlan options support
because we need to be able to send vlan-only notifications and do larger
vlan netlink dumps. Per-vlan options are needed as we move the control
more to vlans and would like to add per-vlan state (needed for per-vlan
STP and EVPN), per-vlan multicast options and control, and I'm sure
there would be many more per-vlan options coming.
Now we create/delete/dump vlans with the device AF_SPEC attribute which is
fine since we support vlan ranges or use a compact bridge_vlan_info
structure, but that cannot really be extended to support per-vlan options
well. The biggest issue is dumping them - we tried using the af_spec with
a new vlan option attribute but that led to insufficient message size
quickly, also another minor problem with that is we have to dump all vlans
always when notifying which, with options present, can be huge if they have
different options set, so we decided to add new rtm message types
specifically for vlans and register handlers for them and a new bridge vlan
notification nl group for vlan-only notifications.
The new RTM NEW/DEL/GETVLAN types introduced match the current af spec
bridge functionality and in fact use the same helpers.
The new nl format is:
[BRIDGE_VLANDB_ENTRY]
[BRIDGE_VLANDB_ENTRY_INFO] - bridge_vlan_info (either 1 vlan or
range start)
[BRIDGE_VLANDB_ENTRY_RANGE] - range end
This allows to encapsulate a range in a single attribute and also to
create vlans and immediately set options on all of them with a single
attribute. The GETVLAN dump can span multiple messages and dump all the
necessary information. The vlan-only notifications are sent on
NEW/DELVLAN events or when vlan options change (currently only flags),
we try hard to compress the vlans into ranges in the notifications as
well. When the per-vlan options are added we'll add helpers to check for
option equality between neighbor vlans and will keep compressing them
when possible.
Note patch 02 is not really required, it's just a nice addition to have
human-readable error messages from the different vlan checks.
iproute2 changes and selftests will be sent with the next set which adds
the first per-vlan option - per-vlan state similar to the port state.
v2: changed patch 03 and patch 04 to use nlmsg_parse() in order to
strictly validate the msg and make sure there are no remaining bytes
Thank you,
Nik
Nikolay Aleksandrov (8):
net: bridge: vlan: add helpers to check for vlan id/range validity
net: bridge: netlink: add extack error messages when processing vlans
net: bridge: vlan: add rtm definitions and dump support
net: bridge: vlan: add new rtm message support
net: bridge: vlan: add del rtm message support
net: bridge: vlan: add rtm range support
net: bridge: vlan: add rtnetlink group and notify support
net: bridge: vlan: notify on vlan add/delete/change flags
include/uapi/linux/if_bridge.h | 29 ++
include/uapi/linux/rtnetlink.h | 9 +
net/bridge/br_netlink.c | 61 +++--
net/bridge/br_private.h | 90 +++++++
net/bridge/br_vlan.c | 473 +++++++++++++++++++++++++++++++--
security/selinux/nlmsgtab.c | 5 +-
6 files changed, 632 insertions(+), 35 deletions(-)
--
2.21.0
Powered by blists - more mailing lists