diff mbox series

[v2] net/mlx5: fix hypervisor detection in VLAN workaround

Message ID 20241206142605.2582139-1-viacheslavo@nvidia.com (mailing list archive)
State Awaiting Upstream
Delegated to: Raslan Darawsheh
Headers
Series [v2] net/mlx5: fix hypervisor detection in VLAN workaround |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/intel-Functional success Functional PASS
ci/iol-marvell-Functional success Functional Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/github-robot: build success github build: passed
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-compile-amd64-testing success Testing PASS

Commit Message

Slava Ovsiienko Dec. 6, 2024, 2:26 p.m. UTC 
The mlx5 PMD provides a specific workaround for the VMware ESXi
hypervisor, enabling on-demand routing configuration to virtual
machines. This workaround activates when the device type is
a Virtual Function and either an ESXi hypervisor is detected
or the hypervisor type is unknown.

For non-x86 architectures the function rte_hypervisor_get()
consistently returns an unknown type, which triggers the workaround
automatically without any actual needs. If there are VLAN support
requirements, this can lead to failures in inserting default control
flows.

Do not trigger the workaround for unknown hypervisor type
in non-x86 environments.

Fixes: dfedf3e3f9d2 ("net/mlx5: add workaround for VLAN in virtual machine")
Cc: stable@dpdk.org

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

--
v2: updated cooments to remove "white list"
---
 drivers/net/mlx5/linux/mlx5_vlan_os.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Comments

Thomas Monjalon Dec. 12, 2024, 10:52 a.m. UTC | #1 
06/12/2024 15:26, Viacheslav Ovsiienko:
> The mlx5 PMD provides a specific workaround for the VMware ESXi
> hypervisor, enabling on-demand routing configuration to virtual
> machines. This workaround activates when the device type is
> a Virtual Function and either an ESXi hypervisor is detected
> or the hypervisor type is unknown.
> 
> For non-x86 architectures the function rte_hypervisor_get()
> consistently returns an unknown type, which triggers the workaround
> automatically without any actual needs. If there are VLAN support
> requirements, this can lead to failures in inserting default control
> flows.
> 
> Do not trigger the workaround for unknown hypervisor type
> in non-x86 environments.

It would be a lot better to fix rte_hypervisor_get().
I suggest starting with the read of /sys/class/dmi/id/
Stephen Hemminger Dec. 12, 2024, 5:27 p.m. UTC | #2 
On Thu, 12 Dec 2024 11:52:51 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 06/12/2024 15:26, Viacheslav Ovsiienko:
> > The mlx5 PMD provides a specific workaround for the VMware ESXi
> > hypervisor, enabling on-demand routing configuration to virtual
> > machines. This workaround activates when the device type is
> > a Virtual Function and either an ESXi hypervisor is detected
> > or the hypervisor type is unknown.
> > 
> > For non-x86 architectures the function rte_hypervisor_get()
> > consistently returns an unknown type, which triggers the workaround
> > automatically without any actual needs. If there are VLAN support
> > requirements, this can lead to failures in inserting default control
> > flows.
> > 
> > Do not trigger the workaround for unknown hypervisor type
> > in non-x86 environments.  
> 
> It would be a lot better to fix rte_hypervisor_get().
> I suggest starting with the read of /sys/class/dmi/id/

The common heuristic is what is in the lscpu utility.
	https://github.com/util-linux/util-linux/sys-utils/lscpu-virt.c

Doing all this right is complex.

PS: it should also detect Xen and others even though DPDK doesn' support it.
Thomas Monjalon Dec. 13, 2024, 7:15 a.m. UTC | #3 
12/12/2024 18:27, Stephen Hemminger:
> On Thu, 12 Dec 2024 11:52:51 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 06/12/2024 15:26, Viacheslav Ovsiienko:
> > > The mlx5 PMD provides a specific workaround for the VMware ESXi
> > > hypervisor, enabling on-demand routing configuration to virtual
> > > machines. This workaround activates when the device type is
> > > a Virtual Function and either an ESXi hypervisor is detected
> > > or the hypervisor type is unknown.
> > > 
> > > For non-x86 architectures the function rte_hypervisor_get()
> > > consistently returns an unknown type, which triggers the workaround
> > > automatically without any actual needs. If there are VLAN support
> > > requirements, this can lead to failures in inserting default control
> > > flows.
> > > 
> > > Do not trigger the workaround for unknown hypervisor type
> > > in non-x86 environments.  
> > 
> > It would be a lot better to fix rte_hypervisor_get().
> > I suggest starting with the read of /sys/class/dmi/id/
> 
> The common heuristic is what is in the lscpu utility.
> 	https://github.com/util-linux/util-linux/sys-utils/lscpu-virt.c
> 
> Doing all this right is complex.
> 
> PS: it should also detect Xen and others even though DPDK doesn' support it.

I don't think we need to detect all.
Currently we have a very limited implementation, using only CPUID on x86.
Bing Zhao June 5, 2025, 3:06 a.m. UTC | #4 
Hi,

Since it is only a WA and no need to consider all archs or CPU types, LGTM so far.

> -----Original Message-----
> From: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> Sent: Friday, December 6, 2024 10:26 PM
> To: dev@dpdk.org
> Cc: Raslan Darawsheh <rasland@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> Suanming Mou <suanmingm@nvidia.com>; stable@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix hypervisor detection in VLAN workaround
> 
> External email: Use caution opening links or attachments
> 
> 
> The mlx5 PMD provides a specific workaround for the VMware ESXi
> hypervisor, enabling on-demand routing configuration to virtual machines.
> This workaround activates when the device type is a Virtual Function and
> either an ESXi hypervisor is detected or the hypervisor type is unknown.
> 
> For non-x86 architectures the function rte_hypervisor_get() consistently
> returns an unknown type, which triggers the workaround automatically
> without any actual needs. If there are VLAN support requirements, this can
> lead to failures in inserting default control flows.
> 
> Do not trigger the workaround for unknown hypervisor type in non-x86
> environments.
> 
> Fixes: dfedf3e3f9d2 ("net/mlx5: add workaround for VLAN in virtual
> machine")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> 
> --
> v2: updated cooments to remove "white list"
> ---
>  drivers/net/mlx5/linux/mlx5_vlan_os.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/mlx5/linux/mlx5_vlan_os.c
> b/drivers/net/mlx5/linux/mlx5_vlan_os.c
> index 81611a8d3f..353484de3f 100644
> --- a/drivers/net/mlx5/linux/mlx5_vlan_os.c
> +++ b/drivers/net/mlx5/linux/mlx5_vlan_os.c
> @@ -112,16 +112,16 @@ mlx5_vlan_vmwa_init(struct rte_eth_dev *dev,
> uint32_t ifindex)
>         /* Check whether there is desired virtual environment */
>         hv_type = rte_hypervisor_get();
>         switch (hv_type) {
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_X86_64)
> +       /* Always misdetected on ARM archs, let's ignore this */
>         case RTE_HYPERVISOR_UNKNOWN:
> +#endif
>         case RTE_HYPERVISOR_VMWARE:
> -               /*
> -                * The "white list" of configurations
> -                * to engage the workaround.
> -                */
> +               /* The list of configurations to engage the workaround.
> + */
>                 break;
>         default:
>                 /*
> -                * The configuration is not found in the "white list".
> +                * The configuration is not found in the list.
>                  * We should not engage the VLAN workaround.
>                  */
>                 return NULL;
> --
> 2.34.1

Acked-by: Bing Zhao <bingz@nvidia.com>
Raslan Darawsheh June 10, 2025, 1:18 p.m. UTC | #5 
Hi,


On 06/12/2024 4:26 PM, Viacheslav Ovsiienko wrote:
> The mlx5 PMD provides a specific workaround for the VMware ESXi
> hypervisor, enabling on-demand routing configuration to virtual
> machines. This workaround activates when the device type is
> a Virtual Function and either an ESXi hypervisor is detected
> or the hypervisor type is unknown.
> 
> For non-x86 architectures the function rte_hypervisor_get()
> consistently returns an unknown type, which triggers the workaround
> automatically without any actual needs. If there are VLAN support
> requirements, this can lead to failures in inserting default control
> flows.
> 
> Do not trigger the workaround for unknown hypervisor type
> in non-x86 environments.
> 
> Fixes: dfedf3e3f9d2 ("net/mlx5: add workaround for VLAN in virtual machine")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> 

Patch applied to next-net-mlx,

Kindest regards
Raslan Darawsheh
diff mbox series

Patch

diff --git a/drivers/net/mlx5/linux/mlx5_vlan_os.c b/drivers/net/mlx5/linux/mlx5_vlan_os.c
index 81611a8d3f..353484de3f 100644
--- a/drivers/net/mlx5/linux/mlx5_vlan_os.c
+++ b/drivers/net/mlx5/linux/mlx5_vlan_os.c
@@ -112,16 +112,16 @@  mlx5_vlan_vmwa_init(struct rte_eth_dev *dev, uint32_t ifindex)
 	/* Check whether there is desired virtual environment */
 	hv_type = rte_hypervisor_get();
 	switch (hv_type) {
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_X86_64)
+	/* Always misdetected on ARM archs, let's ignore this */
 	case RTE_HYPERVISOR_UNKNOWN:
+#endif
 	case RTE_HYPERVISOR_VMWARE:
-		/*
-		 * The "white list" of configurations
-		 * to engage the workaround.
-		 */
+		/* The list of configurations to engage the workaround. */
 		break;
 	default:
 		/*
-		 * The configuration is not found in the "white list".
+		 * The configuration is not found in the list.
 		 * We should not engage the VLAN workaround.
 		 */
 		return NULL;