From: Roopa Prabhu <roopa@cumulusnetworks•com>
To: Jamal Hadi Salim <jhs@mojatatu•com>
Cc: John Fastabend <john.fastabend@gmail•com>,
Hubert Sokolowski <h.sokolowski@wit•edu.pl>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Vlad Yasevich <vyasevic@redhat•com>,
Shrijeet Mukherjee <shm@cumulusnetworks•com>
Subject: Re: SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
Date: Sun, 21 Dec 2014 11:08:03 -0800 [thread overview]
Message-ID: <54971A93.6050700@cumulusnetworks.com> (raw)
In-Reply-To: <5496D8E2.1090700@mojatatu.com>
On 12/21/14, 6:27 AM, Jamal Hadi Salim wrote:
>
> Sorry for the latency, Ive been down with a bad flu (its bad when i cant
> type on my keyboard sitting infront of me;->), recovering and the
> thread seems to have caught on - should be able to catchup in the
> next few days.
> I am beginning to reach a conclusion that the current switchdev approach
> is *not* going to work for SRIOV. I also worry it may be too late
> to change that.
> Shrijeet wanted to set up a BOF for netdev to have hopefully final
> consensus. Shrijeet, are you going to make an official request for the
> BOF?
>
> Sorry John, I dont have enough energy to address all your points but i
> will try to just focus on SRIOV and will save a few bytes while at it.
>
>
> On 12/16/14 11:35, John Fastabend wrote:
>
>> But in the SR-IOV case you have multiple "Cpu ports" and you want
>> to send packets to each of them depending on the configuration.
>>
>>
>> port0 port1 port2 port3
>> | | | | uplinks
>> +------------------------------+
>> | |
>> | SRIOV edge relay |
>> | |
>> +------------------------------+
>> | downlink
>>
>>
>
> Two points above:
> 1) Did you flip uplink vs down link above?
> (I Thought URP was the wire link)
> 2) What you are not showing above which is *very important* is that
> infact there is an underlying embedded fdb.
>
> point #2 brings out a lot of the weird things in some of the bridge
> code. IOW, you have an *offloaded* bridge with _bridge ports_
> visible in the kernel but not the bridge that is controlled
> by standard Linux bridge tools. I am not saying that the model is
> wrong; on the contrary what Ben had exposed may fall under the
> same category i.e you have E_BRIDGE flag on the netdev to say it sits
> on top of an offloaded bridge and you dont need a br0 to run
> bridge command on. But then we need some proxy (TheClassThingy) to act
> as intemediary to the offloaded hardware.
> If you do that then the vf becomes simply a bridge port - which
> means bridge port ops apply.
>
> SRIOV it seems to have morphed its own toolkit.
> The PF port, when acting as the control interface, is actually
> TheClassThingy we discuss on/off.
> To add an fdb entry to point to vf 1, where TheClassThingy is eth1:
> ip link set eth1 vf 1 mac aa:bb:cc:dd:ee:ff vlan 10
>
> IMO, SRIOV should expose these ports with names and ifindices
> (probably does already) and pre-populated master or something
> which points to its parent, then i can do the following:
> bridge fdb add aa:bb:cc:dd:ee:ff vlan 10 dev vf1 master
I had a slightly different understanding of how this would work for
SRIOV. So, am attempting to respond to your questions for John..., ...so
that he can correct my understanding too ..if needed :).
I think SRIOV VF's do have netdevs (John can confirm, I maybe wrong). To
me if SRIOV has a single fdb for all VF's under a PF,
and it wants to bypass the bridge driver, there is still no reason to
refer to the PF as a master.
You can use self and go to the vf driver directly and it will do the
right thing.
bridge fdb add aa:bb:cc:dd:ee:ff vlan 10 dev vf1 self
>
> master in such a case will go to TheClassThingy which would pass
> such control to the underlying hardware.
> The PF still stays but not as the management interface.
Even if 'TheClassThingy' where there, you wouldn't refer to it as the
master (ie the PF will not have a netdev master/slave relationship with
the VF). 'master' will still be used for the netdev 'upper' device if
VF was enslaved to one (which could be a bridge).
Thanks,
Roopa
next prev parent reply other threads:[~2014-12-21 19:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 19:37 [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined Hubert Sokolowski
2014-12-11 4:32 ` David Miller
2014-12-11 11:49 ` Jamal Hadi Salim
2014-12-11 16:51 ` Hubert Sokolowski
2014-12-11 7:31 ` Roopa Prabhu
2014-12-11 16:39 ` Hubert Sokolowski
2014-12-11 18:47 ` Arad, Ronen
2014-12-11 17:06 ` Hubert Sokolowski
2014-12-11 17:32 ` Roopa Prabhu
2014-12-11 20:40 ` Jamal Hadi Salim
2014-12-12 11:38 ` Hubert Sokolowski
2014-12-12 11:54 ` Jamal Hadi Salim
2014-12-12 13:36 ` Hubert Sokolowski
2014-12-12 14:35 ` Jamal Hadi Salim
2014-12-12 20:05 ` John Fastabend
2014-12-15 14:29 ` Jamal Hadi Salim
2014-12-16 0:45 ` John Fastabend
2014-12-16 13:06 ` Jamal Hadi Salim
2014-12-16 14:35 ` Hubert Sokolowski
2014-12-16 16:35 ` John Fastabend
2014-12-16 17:21 ` Samudrala, Sridhar
2014-12-16 19:30 ` Roopa Prabhu
2014-12-16 20:11 ` Samudrala, Sridhar
2014-12-17 5:54 ` Roopa Prabhu
2014-12-21 14:27 ` SRIOV as bridge " Jamal Hadi Salim
[not found] ` <443500166.23675449.1419179623398.JavaMail.zimbra@cumulusnetworks.com>
2014-12-21 16:33 ` Shrijeet Mukherjee
2014-12-21 19:08 ` Roopa Prabhu [this message]
2014-12-21 19:19 ` Jamal Hadi Salim
2014-12-21 19:36 ` Roopa Prabhu
2014-12-21 20:06 ` Jamal Hadi Salim
2014-12-21 20:46 ` Roopa Prabhu
2014-12-22 3:13 ` Jamal Hadi Salim
2014-12-22 6:24 ` Roopa Prabhu
2014-12-22 12:10 ` Jamal Hadi Salim
2014-12-22 13:04 ` Jamal Hadi Salim
2014-12-21 19:52 ` John Fastabend
2014-12-22 2:59 ` Jamal Hadi Salim
2014-12-21 14:46 ` SRIOV fdb and modes WAS(Re: " Jamal Hadi Salim
2014-12-17 5:51 ` Roopa Prabhu
2014-12-17 15:39 ` Vlad Yasevich
2014-12-17 16:18 ` Hubert Sokolowski
2014-12-18 22:32 ` Jamal Hadi Salim
2014-12-19 15:17 ` Hubert Sokolowski
2014-12-19 16:32 ` Roopa Prabhu
2015-01-05 12:56 ` Hubert Sokolowski
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=54971A93.6050700@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=h.sokolowski@wit$(echo .)edu.pl \
--cc=jhs@mojatatu$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shm@cumulusnetworks$(echo .)com \
--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