netdev - RE: bnx2x + SR-IOV, no internal L2 switching

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 12 Feb 2014 14:38:41 +0000
From:	Ariel Elior <ariele@...adcom.com>
To:	"yoann.juet@...v-nantes.fr" <yoann.juet@...v-nantes.fr>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: bnx2x + SR-IOV, no internal L2 switching

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Yoann Juet
> Sent: Wednesday, February 12, 2014 3:34 PM
> To: netdev@...r.kernel.org
> Subject: bnx2x + SR-IOV, no internal L2 switching

Hi Yoan,
57810 device does support l2 switching.
I find your terminology a little bit confusing and I have some further questions besides:

[Q1]: Are you attaching physical functions to VMs? I.e. are you passing through PFs to the VMs, or only virtual functions?

[Q2]: Are you using VFs only on VMs, or directly from the Hypervisor too?

[Q3]: You wrote "for instance the physical ethX has an IP address". That in itself is no problem and no surprise. You gave this as an example to traffic arriving where is shouldn't. Please elaborate.

[Q4]: Do you have vlan filters configured anywhere in your topology? Are they configured from Host or from Guest?
(in this respect host tagging would be 'ip link set eth0 vf 5 vlan 100' on the hypervisor while guest tagging would be 'ip link add link eth4 type vlan id 100' or 'vconfig add eth4 100' where eth0 is a PF and eth4 is a VF).

[Q5]: In the case you mentioned where you saw in a VM traffic which was destined to another VM: Did both VMs contain VFs? Were the VFs created from the same Physical Function? If not, what were the BDFs pf the respective PFs? Which mac addresses did you give the VFs?

[Q6]: Please isolate a specific case where switching is not behaving as expected and describe it in more detail:
Please describe the topology (which PFs are involved and which VFs. Who is assigned to which VMs)
Where are you sending data from (a VF, a PF, some peer on the network) and where is it arriving (perhaps arriving in multiple places)
Please detail the behavior you expect and the behavior you observe.
Please supply:
Mac addresses, ip addresses and masks, configured vlans (if any), promiscuous setting, etc.
ip -d -d link show on hypervisor and each of the VMs involved
ethtool -d from Hypervisor PFs 
dmesg from hypervisor

Please note we recently submitted some fixes to our tx-switching behavior:
In e8379c79 "bnx2x: fix VLAN configuration for VFs" we fixed an issue where traffic with the wrong vlan could still end up in a VM configured to a different vlan (hence my questions on vlans).
In c14db202 "bnx2x: Correct default Tx switching behavior" we fixed a connectivity issue with pf to vf connectivity.
Depending on your answers to the above, perhaps these might be relevant to your case.

Thanks,
Ariel
--
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