netdev - Re: [PATCH 13/23 v3] mlx4: Unicast Loopback support

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] [day] [month] [year] [list]

Date:	Wed, 17 Feb 2010 14:15:51 +0200
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Yevgeny Petrilin <yevgenyp@...lanox.co.il>
Cc:	Roland Dreier <rdreier@...co.com>, netdev@...r.kernel.org,
	liranl@...lanox.co.il, tziporet@...lanox.co.il
Subject: Re: [PATCH 13/23 v3] mlx4: Unicast Loopback support

Yevgeny Petrilin <yevgenyp@...lanox.co.il> wrote:
> I am referring to the case where two VMs are served by two different VFs. The HW checks this field and decides
> whether the packet is loopback or not (by checking whether the written mac matches one of the registered macs on this device).

okay good. I'd be glad to understand what setting/instrumentation has
to be made to the PF driver code to allow for VF/VF traffic to be
either internally switched by the PF HW or be forwarded to the PF
uplink for external switch doing the job (VEPA mode).

I don't think you have to explicitly allow this in the initial
patchset, just try to make it easy to patch.

Or.
--
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