From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
netdev@vger.kernel.org, davem@davemloft.net,
nikolay@cumulusnetworks.com, tgraf@suug.ch,
hannes@stressinduktion.org, jbenc@redhat.com, pshelar@ovn.org,
dsa@cumulusnetworks.com, hadi@mojatatu.com
Subject: Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support
Date: Thu, 02 Feb 2017 06:33:21 -0800 [thread overview]
Message-ID: <58934331.1090106@cumulusnetworks.com> (raw)
In-Reply-To: <20170201230614.0b2a2163@xeon-e3>
On 2/1/17, 11:06 PM, Stephen Hemminger wrote:
> On Wed, 01 Feb 2017 21:58:25 -0800
> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
>> On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
>>> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>>>
>>
[snip]
>>> I think most swith asics can do other tunnels too,
>>> so can this vlan->vxlan 1 to 1 be generalized to cover different
>>> types of tunnels that can be configured on the switch?
>>
>> yes, it can be. Hence i have kept the tunnel info netlink attribute generic. similar to how LWT provides
>> various encaps at the L3 routing layer, this can provide such function at the L2 bridge layer. But, to keep it relatively lite I use the
>> already existing dst_metadata infra to bridge vlan to vxlan (Which is already done in the case of vxlan collect metadata mode.
>> I simply extend it to cover the bridge case).
>>
>> thanks,
> I wonder if this is a case for a new driver (with same subset of bridge API). You probably
> don't want all the baggage of STP, netfilter, VLAN filtering, etc when doing VXLAN VNI bridging.
We do want stp, netfilter, VLAN filtering, igmp snooping on the same bridge. In-fact this vlan-to-tunnel incremental feature I add here is only
available to the vlan filtering bridge.
It is in our best interest to make or keep the bridge driver suitable for all architectures. You have seen the bridge perf fixes from nikolay
recently, all those are towards the same effort. Nikolay has had a bunch of cleanup ideas and has been contributing patches to that effect.
I think we should work on cleaning up and fixing the current bridge driver instead of introducing a new one. The bridge driver has a nice api which has been working great for various deployments...(like i mention, also for the hardware offload case).
If you have any performance numbers or data from other architectures, we would be happy to take a look and see what we can do more.
next prev parent reply other threads:[~2017-02-02 14:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 6:59 [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support Roopa Prabhu
2017-02-01 6:59 ` [PATCH net-next v2 1/5] ip_tunnels: new IP_TUNNEL_INFO_BRIDGE flag for ip_tunnel_info mode Roopa Prabhu
2017-02-01 6:59 ` [PATCH net-next v2 2/5] vxlan: support fdb and learning in COLLECT_METADATA mode Roopa Prabhu
2017-02-11 4:05 ` Joe Stringer
2017-02-11 4:55 ` Roopa Prabhu
2017-02-01 6:59 ` [PATCH net-next v2 3/5] bridge: uapi: add per vlan tunnel info Roopa Prabhu
2017-02-01 6:59 ` [PATCH net-next v2 4/5] bridge: per vlan dst_metadata netlink support Roopa Prabhu
2017-02-01 6:59 ` [PATCH net-next v2 5/5] bridge: vlan dst_metadata hooks in ingress and egress paths Roopa Prabhu
2017-02-02 1:23 ` [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support Alexei Starovoitov
2017-02-02 1:59 ` David Ahern
2017-02-02 4:02 ` Roopa Prabhu
2017-02-02 4:04 ` Stephen Hemminger
2017-02-02 5:07 ` Roopa Prabhu
2017-02-02 5:58 ` Roopa Prabhu
2017-02-02 7:06 ` Stephen Hemminger
2017-02-02 14:33 ` Roopa Prabhu [this message]
2017-02-03 1:50 ` David Miller
2017-02-03 6:06 ` Roopa Prabhu
2017-02-03 20:21 ` 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=58934331.1090106@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=hadi@mojatatu.com \
--cc=hannes@stressinduktion.org \
--cc=jbenc@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=pshelar@ovn.org \
--cc=stephen@networkplumber.org \
--cc=tgraf@suug.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.