On 11/28/2018 5:15 PM, Michael S. Tsirkin wrote:
On Wed, Nov 28, 2018 at 12:28:42PM -0800, si-wei liu wrote:
On 11/28/2018 12:06 PM, Michael S. Tsirkin wrote:
On Wed, Nov 28, 2018 at 10:39:55AM -0800, Samudrala, Sridhar wrote:
On 11/28/2018 9:35 AM, Michael S. Tsirkin wrote:
On Wed, Nov 28, 2018 at 09:31:32AM -0800, Samudrala, Sridhar wrote:
On 11/28/2018 9:08 AM, Michael S. Tsirkin wrote:
On Mon, Nov 26, 2018 at 12:22:56PM -0800, Samudrala, Sridhar wrote:
Update:
I have just set the vf mac's address to 0 (ip link set ens2f0 vf 1 mac
00:00:00:00:00:00) after unplugging it (the primary device) and the
pings started working again on the failover interface. So it seems
like the frames were arriving to the vf on the host.
Yes. When the VF is unplugged, you need to reset the VFs MAC so that the packets
with VMs MAC start flowing via VF, bridge and the virtio interface.
Have you looked at this documentation that shows a sample script to initiate
live
migration?
https://www.kernel.org/doc/html/latest/networking/net_failover.html
-Sridhar
Interesting I didn't notice it does this. So in fact
just defining VF mac will immediately divert packets
to the VF? Given guest driver did not initialize VF
yet won't a bunch of packets be dropped?
There is typo in my stmt above (VF->PF)
When the VF is unplugged, you need to reset the VFs MAC so that the packets
with VMs MAC start flowing via PF, bridge and the virtio interface.
When the VF is plugged in, ideally the MAC filter for the VF should be added to
the HW once the guest driver comes up and can receive packets. Currently with
intel
drivers, the filter gets added to HW as soon as the host admin sets the VFs MAC
via
ndo_set_vf_mac() api. So potentially there could be packet drops until the VF
driver
comes up in the VM.
Can this be fixed in the intel drivers?
I just checked and it looks like this seems to have been addressed in the
ice 100Gb driver. Will bring this up issue internally to see if we can change
this
behavior in i40e/ixgbe drivers.
Also what happens if the mac is programmed both in PF (e.g. with
macvtap) and VF? Ideally VF will take precedence.
I'm seriously doubtful that legacy Intel NIC hardware can do that instead of
mucking around with software workaround in the PF driver. Actually, the same
applies to other NIC vendors when hardware sees duplicate filters. There's
no such control of precedence on one over the other.
-Siwei
Well removing a MAC from the PF filter when we are adding it to the VF
filter should always be possible. Need to keep it in a separate list and
re-add it when removing the MAC from VF filter. This can be handled in
the net core, no need for driver specific hacks.
So that is what I ever said - essentially what you need is a netdev API,
rather than to add dirty hacks on each driver. That is fine, but how
would you implement it? Note there's no equivalent driver level .ndo API
to "move" filters, and all existing .ndo APIs manipulate at the MAC
address level as opposed to filters. Are you going to convince netdev
this is the right thing to do and we should add such API to the net core
and each individual driver?
Still, let's prioritize things correctly. IMHO it's fine if we
initially assume promisc mode on the PF. macvlan has this mode too
after all.
I'm not sure what promisc mode you talked about. As far as I understand
it for macvlan/macvtap the NIC is only put into promisc mode when
running out of MAC filter entries. Before that all MAC addresses will be
added to the NIC as unicast filters. In addition, people prefer
macvlan/macvtap for adding isolation in a multi-tenant cloud as well as
avoiding performance penalty due to noisy neighbors. I'd rather to hear
that claim to be that the current MAC-based pairing scheme doesn't work
well with macvtap and only works with bridged setup which has promisc
enabled. That would be more helpful for people to understand the
situation better.
Thanks,
-Siwei
Question is how does userspace know driver isn't broken in this respect?
Let's add a "vf failover" flag somewhere so this can be probed?
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org