[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B7AB9A6.1090209@mellanox.co.il>
Date: Tue, 16 Feb 2010 17:28:38 +0200
From: Yevgeny Petrilin <yevgenyp@...lanox.co.il>
To: or.gerlitz@...il.com
CC: Yevgeny Petrilin, 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
On Sunday -10,January,-28163 09:59 PM, Or Gerlitz [or.gerlitz@...il.com] wrote:
> Yevgeny Petrilin <yevgenyp@...lanox.co.il> wrote:
>> Or Gerlitz [or.gerlitz@...il.com] wrote:
>
>>> I wasn't sure what is the use case here, isn't loopback handled by higher levels at the network stack?
>
>> The use case is two VMs using the same physical adapter.
>
> I am still not with you: are you referring to the case where each VM is being served by a different VF? in that case, the VF driver (mlx4_en) has no way to know its a "loopback" packet, and switching between VFs can be programmed to the PF by the PF driver (modified mlx4_core).
>
> If you are talking to the case both VMs are being served by the same PCI function --> same NIC then again, loopback is handled in higher level.
>
> Is there a 3rd use case?
>
> Or.
There is no third case. I am referring to the case where two VMs are served by two different VFs.
The mlx4_en driver doesn't know whether a packet is loopback or not, it assumes that all packets can
be loopbacks and writes the dmac to the control segment.
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).
--
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