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  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]
Date:	Sun, 21 Dec 2014 09:46:04 -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>
Subject: SRIOV fdb and modes WAS(Re: [PATCH net-next RESEND] net: Do not call
 ndo_dflt_fdb_dump if ndo_fdb_dump is defined.


John,

On CPU port: Yes, a VF with PCIE params is considered a "CPU port".
This is fine for SRIOV because it ties VF to a "CPU port". Other
ASIC models have an explicit single "CPU port" (I would say the tiny
openwrt types or larger broadcom switches). In such a case you program
separately the cpu MAC addresses and then you teach some table to
send to the CPU port. It doesnt matter whether it is L2 or L3. As
an example you can point a L3 NH to cpu port with a CPU port MAC address
so things dont show up as skb HOST tagged on the stack.
On Linux infact without the concept of an fdb - this is also true.
i.e not all NICs have an fdb. Macvlan was initially introduced (Patrick
McHardy iirc) to expose the multiple MAC address a standard NIC has.
Conflating this with having an fdb is where the water got mudied in my
opinion. I should be able to dump these MAC addresses without expecting
that i need to talk to an underlying hardware dumper (hence the default
dumper). Unless it is true today that _all_ NICs with multiple MACs have
an embedded fdb.
To summarize: I dont think we disagree much - i just wanted to emphasize
the concept of "cpu port" being important.

Other thing you brought up was the concept of uplink/downlink relay
ports.  The more i think about it, the more i am reaching a conclusion
that they are *not* anything speacial.
Essentially, in one case you have the port column pointing to the VF
after you populate the underlying fdb. By default it doesnt seem these
SRIOV switches cant learn. We have knobs for that and capability is
exposable to point to the fact
And it seems to me that VEPA is just a mode where flooding control
points out one port connected externally.
We already have knobs per port flood and learning controls.

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

Powered by blists - more mailing lists