From: Vlad Yasevich <vyasevic@redhat.com>
To: shemminger@vyatta.com
Cc: bridge@lists.linux-foundation.org, davem@davemloft.net,
netdev@vger.kernel.org, shmulik.ladkani@gmail.com
Subject: Re: [PATCH 00/13] Add basic VLAN support to bridges
Date: Tue, 29 Jan 2013 15:09:56 -0500 [thread overview]
Message-ID: <51082C94.7050003@redhat.com> (raw)
In-Reply-To: <1359489180-10012-1-git-send-email-vyasevic@redhat.com>
This is aimed for net-next. Sorry for any confusion.
-vlad
On 01/29/2013 02:52 PM, Vlad Yasevich wrote:
> This is another revision of the VLAN filtering patchset. It offers
> functionality that is similar to what can be found in switches as
> far as VLAN configuration and filtering of frames according to VLAN
> tags.
>
> Each port on the bridge, as well as the bridge itself, can be configured
> with a set of VLANs that they are willing to accept. One of the vlans
> may be chosen as PVID and any untagged traffic will be associated with it.
>
> Changes since v6:
> * VLANs are now stored in a VLAN bitmap per port. This allows for O(1)
> lookup at ingress and egress. We simply check to see if the bit associated
> with the vlan id is set in the map. The drawback to this approach is that
> it wastes some space when there is only a small number of VLANs.
> * In addition to the build time configuration option, VLAN filtering also has
> a configuration paramter in sysfs. By default the filtering is turned off
> and all traffic is permitted. When the filtring is turned on, we do strict
> matching to the filter configured. Thus, if there is no configuration, all
> packets are rejected. This was done to make the behavior more streight
> forward. Without this (and if egress policy patch is rejected), the
> decision for how to forward untagged traffic that was not filtered at ingress
> is almost impossible to make. It would not be right to deliver to every
> port that has PVID set as, each port may have a different PVID.
> * Separate egress policy bitmap patch has been isolated and is provided last
> in the series. This has been a more contentious piece of functionality and I
> wanted to isolate it so that it could easily be dropped and not block the whole
> series.
>
> Changes since v5:
> - Pulled VLAN filtering into its own file and made it a configuration options.
> - Made new vlan filtering option dependent on VLAN_8021Q.
> - Got rid of HW filter inlines and moved then vlan_core.c.
> (All of the above suggested by Stephen Hemminger)
>
> Changes since v4:
> - Pull per-port vlan data into its own structures and give it to the bridge
> device thus making bridge device behave like a regular port for vlan
> configuration.
> - Add a per-vlan 'untagged' bitmap that determins egress policy. If a port
> is part of this bitmap, traffic egresses untagged.
> - PVID is now used for ingress policy only. Incomming frames without VLAN tag
> are assigned to the PVID vlan. Egress is determined via bitmap memberships.
> - Allow for incremental config of a vlan. Now, PVID and untagged memberships
> may be set on existing vlans. They however can NOT be cleared separately.
> - VLAN deletion is now done via RTM_DELLINK command for PF_BRIDGE family.
> This cleans up the netlink interface.
>
> Changes since v3:
> - Re-integrated compiler problems that got left out last time. Appologies.
> - checkpatches.pl errors fixed
>
> Changes since v2:
> - Added inline functiosn to manimulate vlan hw filters and re-use in 8021q
> and bridge code.
> - Use rtnl_dereference (Michael Tsirkin)
> - Remove synchronize_net() call (Eric Dumazet)
> - Fix NULL ptr deref bug I introduced in br_ifinfo_notify.
>
> Changes since v1:
> - Fixed some forwarding bugs.
> - Add vlan to local fdb entries. New local entries are created per vlan
> to facilite correct forwarding to bridge interface.
> - Allow configuration of vlans directly on the bridge master device
> in addition to ports.
>
> Changes since rfc v2:
> - Per-port vlan bitmap is gone and is replaced with a vlan list.
> - Added bridge vlan list, which is referenced by each port. Entries in
> the birdge vlan list have port bitmap that shows which port are parts
> of which vlan.
> - Netlink API changes.
> - Dropped sysfs support for now. If people think this is really usefull,
> can add it back.
> - Support for native/untagged vlans.
>
> Changes since rfc v1:
> - Comments addressed regarding formatting and RCU usage
> - iocts have been removed and changed over the netlink interface.
> - Added support of user added ndb entries.
> - changed sysfs interface to export a bitmap. Also added a write interface.
> I am not sure how much I like it, but it made my testing easier/faster. I
> might change the write interface to take text instead of binary.
>
> Vlad Yasevich (13):
> vlan: wrap hw-acceleration calls in separate functions.
> bridge: Add vlan filtering infrastructure
> bridge: Validate that vlan is permitted on ingress
> bridge: Verify that a vlan is allowed to egress on give port
> bridge: Add netlink interface to configure vlans on bridge ports
> bridge: Add the ability to configure pvid
> bridge: Implement vlan ingress/egress policy
> bridge: Add vlan to unicast fdb entries
> bridge: Add vlan id to multicast groups
> bridge: Add vlan support to static neighbors
> bridge: Add vlan support for local fdb entries
> bridge: Dump vlan information from a bridge port
> bridge: Separate egress policy bitmap
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +-
> drivers/net/macvlan.c | 2 +-
> drivers/net/vxlan.c | 3 +-
> include/linux/if_vlan.h | 21 ++
> include/linux/netdevice.h | 6 +-
> include/uapi/linux/if_bridge.h | 13 +-
> include/uapi/linux/neighbour.h | 1 +
> include/uapi/linux/rtnetlink.h | 1 +
> net/8021q/vlan.c | 4 +-
> net/8021q/vlan_core.c | 82 ++++-
> net/bridge/Kconfig | 14 +
> net/bridge/Makefile | 2 +
> net/bridge/br_device.c | 7 +-
> net/bridge/br_fdb.c | 259 ++++++++++++---
> net/bridge/br_forward.c | 9 +
> net/bridge/br_if.c | 4 +-
> net/bridge/br_input.c | 28 ++-
> net/bridge/br_multicast.c | 69 +++--
> net/bridge/br_netlink.c | 239 ++++++++++++--
> net/bridge/br_private.h | 153 ++++++++-
> net/bridge/br_sysfs_br.c | 21 ++
> net/bridge/br_vlan.c | 448 +++++++++++++++++++++++++
> net/core/rtnetlink.c | 111 ++++++-
> 23 files changed, 1354 insertions(+), 148 deletions(-)
> create mode 100644 net/bridge/br_vlan.c
>
next prev parent reply other threads:[~2013-01-29 20:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 19:52 [PATCH 00/13] Add basic VLAN support to bridges Vlad Yasevich
2013-01-29 19:52 ` [PATCH 01/13] vlan: wrap hw-acceleration calls in separate functions Vlad Yasevich
2013-01-29 19:52 ` [PATCH 02/13] bridge: Add vlan filtering infrastructure Vlad Yasevich
2013-01-29 19:52 ` [PATCH 03/13] bridge: Validate that vlan is permitted on ingress Vlad Yasevich
2013-01-29 19:52 ` [PATCH 04/13] bridge: Verify that a vlan is allowed to egress on give port Vlad Yasevich
2013-01-29 19:52 ` [PATCH 05/13] bridge: Add netlink interface to configure vlans on bridge ports Vlad Yasevich
2013-01-29 19:52 ` [PATCH 06/13] bridge: Add the ability to configure pvid Vlad Yasevich
2013-01-29 19:52 ` [PATCH 07/13] bridge: Implement vlan ingress/egress policy Vlad Yasevich
2013-01-29 19:52 ` [PATCH 08/13] bridge: Add vlan to unicast fdb entries Vlad Yasevich
2013-01-29 19:52 ` [PATCH 09/13] bridge: Add vlan id to multicast groups Vlad Yasevich
2013-01-29 19:52 ` [PATCH 10/13] bridge: Add vlan support to static neighbors Vlad Yasevich
2013-01-29 19:52 ` [PATCH 11/13] bridge: Add vlan support for local fdb entries Vlad Yasevich
2013-01-29 19:52 ` [PATCH 12/13] bridge: Dump vlan information from a bridge port Vlad Yasevich
2013-01-29 19:53 ` [PATCH 13/13] bridge: Separate egress policy bitmap Vlad Yasevich
2013-01-29 20:09 ` Vlad Yasevich [this message]
2013-01-29 21:11 ` [PATCH 00/13] Add basic VLAN support to bridges David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51082C94.7050003@redhat.com \
--to=vyasevic@redhat.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=shmulik.ladkani@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).