From: Jamal Hadi Salim <jhs@mojatatu•com>
To: John Fastabend <john.r.fastabend@intel•com>
Cc: vyasevic@redhat•com,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Stephen Hemminger <stephen@networkplumber•org>,
Scott Feldman <sfeldma@cumulusnetworks•com>
Subject: Re: RFC: bridge get fdb by bridge device
Date: Thu, 13 Feb 2014 07:50:53 -0500 [thread overview]
Message-ID: <52FCBFAD.6000408@mojatatu.com> (raw)
In-Reply-To: <52FBC282.6020301@intel.com>
On 02/12/14 13:50, John Fastabend wrote:
>
> Just to wrap things up in one email. Changing between VEB and VEPA
> modes already triggers an event. So management applications can listen
> for this.
>
Ok - reasonable.
> And I can send out a patch to add a flag to hardware bridge devices
> I'll likely get to it next week sometime unless someone beats me
> to it.
>
You understand this better - so i will wait.
I'll send an updated version of the patch this weekend
now that net-next is open.
>
> Sure, IEEE802.1Q would call these edge relays.
>
Ok, so what older kids used to call "repeaters".
The more i think about it, the more it looks like this is
still a bridge and we have a bridgeport mode as VEPA vs VEB.
IOW, as you said - you can have a bridge with mix and match of
VEB/VEPA. We can easily add such a feature to the software bridge
as well. It sounds simple and useful enough.
>
> Because it is not the same type of object as the software bridge.
> Most notably it doesn't do learning. If anything its more like a
> macvlan device and we could just as easily tag it IFF_MACVLAN. So
> because it doesn't really match 1:1 with either of those object I
> would just presume give its own flag. Userspace can always create
> a small macro call it is_bridge_like() and check for any of the
> handful of bridge like objects.
>
I think VEB/VEP may be somehow covering the "port" aspect.
The challenge is what to call "eth0 when running in SRIOV"
>>>
>>> # ip link set dev bridge0 master bridge1
>>> RTNETLINK answers: Too many levels of symbolic links
>>>
>>
>> pourquoi? If the original rationale was to limit the
>> broadcast domain scope it sounds strange that a bridge in
>> the form a macvlan is allowed.
>>
>
> Agreed. But there it is.
>
I am sure someone knows why - Stephen?
cheers,
jamal
next prev parent reply other threads:[~2014-02-13 12:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52F21F72.2090405@mojatatu.com>
[not found] ` <52F29747.7040008@redhat.com>
[not found] ` <52F3CF76.9090404@mojatatu.com>
[not found] ` <52F3E357.4040006@redhat.com>
2014-02-09 15:06 ` RFC: bridge get fdb by bridge device Jamal Hadi Salim
2014-02-09 19:33 ` John Fastabend
2014-02-11 17:03 ` Jamal Hadi Salim
2014-02-10 16:31 ` Vlad Yasevich
2014-02-11 17:07 ` Jamal Hadi Salim
2014-02-11 18:21 ` Vlad Yasevich
2014-02-11 20:15 ` Jamal Hadi Salim
2014-02-11 20:21 ` John Fastabend
2014-02-11 20:30 ` John Fastabend
2014-02-11 21:04 ` Jamal Hadi Salim
2014-02-12 18:50 ` John Fastabend
2014-02-13 12:50 ` Jamal Hadi Salim [this message]
2014-02-13 15:37 ` Jamal Hadi Salim
2014-02-13 16:03 ` John Fastabend
2014-02-11 21:00 ` Vlad Yasevich
2014-02-11 21:08 ` Jamal Hadi Salim
2014-02-11 21:12 ` Jamal Hadi Salim
2014-02-12 19:02 ` Vlad Yasevich
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=52FCBFAD.6000408@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sfeldma@cumulusnetworks$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=vyasevic@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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