netdev - SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5496D8E2.1090700@mojatatu.com>
Date:	Sun, 21 Dec 2014 09:27:46 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	John Fastabend <john.fastabend@...il.com>
CC:	Hubert Sokolowski <h.sokolowski@....edu.pl>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Vlad Yasevich <vyasevic@...hat.com>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump
 if ndo_fdb_dump is defined.

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

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.

Ok, promised to keep this short ;-> I should respond to the other points
in a separate email.

cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html