[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A9F7885.8080402@Voltaire.com>
Date: Thu, 03 Sep 2009 11:04:21 +0300
From: Or Gerlitz <ogerlitz@...taire.com>
To: Alexander Duyck <alexander.duyck@...il.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
"Duyck, Alexander H" <alexander.h.duyck@...el.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
David Miller <davem@...emloft.net>
Subject: Re: 2.6.31 ARP related problems
Alexander Duyck wrote:
> I don't suspect this has much of an effect on the Virtualization use case for SR-IOV since the VFs are meant to be direct assigned as PCI devices to the individual VMs
I understand that eventually there will be scheme when VFs will be
directly assigned to the VM, but there are/will be many occasions where
a VF will serve as a virtual NIC in a Linux system e.g one serving as a
host but also other purposes (think on macvlan as "software SR-IOV"
where with your HW its the real thing).
> You can probably also reproduce the issue by placing multiple physical network interfaces on the same network segment if you saw the same effect on SR-IOV since that is essentially the effect the VFs create due to the switching logic built into the 82576
Yes, as I managed to produce it with thee schemes: macvlan, veth+bridge
and SR-IOV, I believe something is just broken wrt to ARP replies in
2.6.31 which is now in its rc8! I will try to look on that, and
hopefully we can fix it at least for -stable.
Or.
I wasn't sure to understand your "the effect the VFs create due to the
switching logic built into the 82576" comment, can you elaborate more on
that?
--
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