-----Original Message----- From: Paolo Abeni pabeni@redhat.com Sent: Thursday, October 3, 2024 5:35 AM To: Haiyang Zhang haiyangz@microsoft.com; linux-hyperv@vger.kernel.org; netdev@vger.kernel.org Cc: KY Srinivasan kys@microsoft.com; wei.liu@kernel.org; Dexuan Cui decui@microsoft.com; edumazet@google.com; kuba@kernel.org; stephen@networkplumber.org; davem@davemloft.net; linux- kernel@vger.kernel.org; stable@vger.kernel.org Subject: Re: [PATCH net] hv_netvsc: Fix VF namespace also in netvsc_open
On 9/27/24 22:54, Haiyang Zhang wrote:
The existing code moves VF to the same namespace as the synthetic
device
during netvsc_register_vf(). But, if the synthetic device is moved to a new namespace after the VF registration, the VF won't be moved
together.
To make the behavior more consistent, add a namespace check to
netvsc_open(),
and move the VF if it is not in the same namespace.
Cc: stable@vger.kernel.org Fixes: c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc
device")
Signed-off-by: Haiyang Zhang haiyangz@microsoft.com
This looks strange to me. Skimming over the code it looks like that with VF you really don't mean a Virtual Function...
Thanks for the review. "VF": I mean "Virtual Function" NIC.
Looking at the blamed commit, it looks like that having both the synthetic and the "VF" device in different namespaces is an intended use-case. This change would make such scenario more difficult and could possibly break existing use-cases.
On Hyper-V / Azure hosts, the synthetic NIC (master) and VF NIC (slave) are transparently bonded, and apps should only interact with the synthetic NIC (master). Using them at two different namespaces is not an intended use case.
We have published documents explaining this: "The synthetic and VF interfaces have the same MAC address. Together, they constitute a single NIC from the standpoint of other network entities that exchange packets with the virtual NIC in the VM. " "IP addresses are assigned only to the synthetic interface." https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networki...
Why do you think it will be more consistent? If the user moved the synthetic device in another netns, possibly/likely the user intended to keep both devices separated.
Consider two Cases: Case 1): - Synthetic NIC is offered. - Run command to move synthetic NIC ip link set <synthetic NIC> netns <new namespace> - VF NIC is offered.
Case 2): - Synthetic NIC is offered. - VF NIC is offered. - Run command to move synthetic NIC ip link set <synthetic NIC> netns <new namespace>
The previous patch: c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc device") automatically moves the VF to the new namespace in Case (1), but not in Case (2).
With this patch, VF will be automatically moved to the new namespace also in the Case (2). So, the behaviors of Case 1 & 2 become consistent. This will make our customers easier to find and check if VF NIC is running, and its stat data.
Thanks, - Haiyang