All of lore.kernel.org
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
@ 2019-05-23 22:01 Stephen Hemminger
  2019-05-24 13:26 ` Ferruh Yigit
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-23 22:01 UTC (permalink / raw)
  To: matan; +Cc: dev, Stephen Hemminger, Stephen Hemminger

Several users have run into problems where the MLX drivers were not
enabled in their build. And then trying to run their DPDK
application on Azure. What happens is that all packets
go over the slow path, and failsafe repeatedly probes for never
existing sub-device.

Both Mellanox drivers should be checked. MLX4 for current versions,
and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
is detected.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
 drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 801f54c96e01..64f9dbf66e18 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
 	struct rte_devargs *devargs;
 	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
 
+#ifndef RTE_LIBRTE_MLX4_PMD
+	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
+#endif
+#ifndef RTE_LIBRTE_MLX5_PMD
+	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
+#endif
+
 	RTE_EAL_DEVARGS_FOREACH("vdev", devargs)
 		if (!strncmp(devargs->name, VDEV_NETVSC_DRIVER_NAME,
 			     VDEV_NETVSC_DRIVER_NAME_LEN))
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-23 22:01 [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured Stephen Hemminger
@ 2019-05-24 13:26 ` Ferruh Yigit
  2019-05-24 16:07   ` Stephen Hemminger
  0 siblings, 1 reply; 11+ messages in thread
From: Ferruh Yigit @ 2019-05-24 13:26 UTC (permalink / raw)
  To: Stephen Hemminger, matan; +Cc: dev, Stephen Hemminger

On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> Several users have run into problems where the MLX drivers were not
> enabled in their build. And then trying to run their DPDK
> application on Azure. What happens is that all packets
> go over the slow path, and failsafe repeatedly probes for never
> existing sub-device.
> 
> Both Mellanox drivers should be checked. MLX4 for current versions,
> and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> is detected.
> 
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
>  drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
> index 801f54c96e01..64f9dbf66e18 100644
> --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
>  	struct rte_devargs *devargs;
>  	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
>  
> +#ifndef RTE_LIBRTE_MLX4_PMD
> +	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> +#endif
> +#ifndef RTE_LIBRTE_MLX5_PMD
> +	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> +#endif

Is it OK a virtual PMD being this much aware of another PMD?
Can it be an option to add this check into build system? And if there is direct
dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
enabled.

> +
>  	RTE_EAL_DEVARGS_FOREACH("vdev", devargs)
>  		if (!strncmp(devargs->name, VDEV_NETVSC_DRIVER_NAME,
>  			     VDEV_NETVSC_DRIVER_NAME_LEN))
> 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 13:26 ` Ferruh Yigit
@ 2019-05-24 16:07   ` Stephen Hemminger
  2019-05-24 16:38     ` Thomas Monjalon
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-24 16:07 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: matan, dev, Stephen Hemminger

On Fri, 24 May 2019 14:26:40 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > Several users have run into problems where the MLX drivers were not
> > enabled in their build. And then trying to run their DPDK
> > application on Azure. What happens is that all packets
> > go over the slow path, and failsafe repeatedly probes for never
> > existing sub-device.
> > 
> > Both Mellanox drivers should be checked. MLX4 for current versions,
> > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > is detected.
> > 
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > ---
> >  drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > index 801f54c96e01..64f9dbf66e18 100644
> > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> >  	struct rte_devargs *devargs;
> >  	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> >  
> > +#ifndef RTE_LIBRTE_MLX4_PMD
> > +	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > +#endif
> > +#ifndef RTE_LIBRTE_MLX5_PMD
> > +	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > +#endif  
> 
> Is it OK a virtual PMD being this much aware of another PMD?
> Can it be an option to add this check into build system? And if there is direct
> dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> enabled.

vdev_netvsc is not a device, it is really just a hack to start other
device drivers on Hyper-V/Azure.  If the build system supported dependencies
(like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
so that doesn't help.

This is a warning and not fatal only because application will still at
least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.


The warning is just to give users better immediate feedback rather than
trying to diagnose poor performance or mystery device not found messages.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 16:07   ` Stephen Hemminger
@ 2019-05-24 16:38     ` Thomas Monjalon
  2019-05-24 16:48       ` Stephen Hemminger
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2019-05-24 16:38 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

24/05/2019 18:07, Stephen Hemminger:
> On Fri, 24 May 2019 14:26:40 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> 
> > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > > Several users have run into problems where the MLX drivers were not
> > > enabled in their build. And then trying to run their DPDK
> > > application on Azure. What happens is that all packets
> > > go over the slow path, and failsafe repeatedly probes for never
> > > existing sub-device.
> > > 
> > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > > is detected.
> > > 
> > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > > ---
> > >  drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > index 801f54c96e01..64f9dbf66e18 100644
> > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > >  	struct rte_devargs *devargs;
> > >  	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > >  
> > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > +	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > +#endif
> > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > +	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > +#endif  
> > 
> > Is it OK a virtual PMD being this much aware of another PMD?
> > Can it be an option to add this check into build system? And if there is direct
> > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> > enabled.
> 
> vdev_netvsc is not a device, it is really just a hack to start other
> device drivers on Hyper-V/Azure.  If the build system supported dependencies
> (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> so that doesn't help.
> 
> This is a warning and not fatal only because application will still at
> least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> 
> 
> The warning is just to give users better immediate feedback rather than
> trying to diagnose poor performance or mystery device not found messages.


It really looks strange to me.
What you need is to fail at compilation if requested PMD is not built.
I would advise to work on a script to configure meson.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 16:38     ` Thomas Monjalon
@ 2019-05-24 16:48       ` Stephen Hemminger
  2019-05-24 17:05         ` Thomas Monjalon
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-24 16:48 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

On Fri, 24 May 2019 18:38:53 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 24/05/2019 18:07, Stephen Hemminger:
> > On Fri, 24 May 2019 14:26:40 +0100
> > Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >   
> > > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:  
> > > > Several users have run into problems where the MLX drivers were not
> > > > enabled in their build. And then trying to run their DPDK
> > > > application on Azure. What happens is that all packets
> > > > go over the slow path, and failsafe repeatedly probes for never
> > > > existing sub-device.
> > > > 
> > > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > > > is detected.
> > > > 
> > > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > > > ---
> > > >  drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > index 801f54c96e01..64f9dbf66e18 100644
> > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > > >  	struct rte_devargs *devargs;
> > > >  	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > > >  
> > > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > > +	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > > +#endif
> > > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > > +	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > > +#endif    
> > > 
> > > Is it OK a virtual PMD being this much aware of another PMD?
> > > Can it be an option to add this check into build system? And if there is direct
> > > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> > > enabled.  
> > 
> > vdev_netvsc is not a device, it is really just a hack to start other
> > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > so that doesn't help.
> > 
> > This is a warning and not fatal only because application will still at
> > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > 
> > 
> > The warning is just to give users better immediate feedback rather than
> > trying to diagnose poor performance or mystery device not found messages.  
> 
> 
> It really looks strange to me.
> What you need is to fail at compilation if requested PMD is not built.
> I would advise to work on a script to configure meson.

None of the people that ran into this were using meson build.
For example, VPP doesn't use meson.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 16:48       ` Stephen Hemminger
@ 2019-05-24 17:05         ` Thomas Monjalon
  2019-05-24 17:11           ` Stephen Hemminger
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2019-05-24 17:05 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

24/05/2019 18:48, Stephen Hemminger:
> On Fri, 24 May 2019 18:38:53 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> > 24/05/2019 18:07, Stephen Hemminger:
> > > On Fri, 24 May 2019 14:26:40 +0100
> > > Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > >   
> > > > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:  
> > > > > Several users have run into problems where the MLX drivers were not
> > > > > enabled in their build. And then trying to run their DPDK
> > > > > application on Azure. What happens is that all packets
> > > > > go over the slow path, and failsafe repeatedly probes for never
> > > > > existing sub-device.
> > > > > 
> > > > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > > > > is detected.
> > > > > 
> > > > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > > > > ---
> > > > >  drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > index 801f54c96e01..64f9dbf66e18 100644
> > > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > > > >  	struct rte_devargs *devargs;
> > > > >  	struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > > > >  
> > > > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > > > +	DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > > > +#endif
> > > > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > > > +	DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > > > +#endif    
> > > > 
> > > > Is it OK a virtual PMD being this much aware of another PMD?
> > > > Can it be an option to add this check into build system? And if there is direct
> > > > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> > > > enabled.  
> > > 
> > > vdev_netvsc is not a device, it is really just a hack to start other
> > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > so that doesn't help.
> > > 
> > > This is a warning and not fatal only because application will still at
> > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > 
> > > 
> > > The warning is just to give users better immediate feedback rather than
> > > trying to diagnose poor performance or mystery device not found messages.  
> > 
> > 
> > It really looks strange to me.
> > What you need is to fail at compilation if requested PMD is not built.
> > I would advise to work on a script to configure meson.
> 
> None of the people that ran into this were using meson build.
> For example, VPP doesn't use meson.

They will use meson when makefile will be removed :)

Anyway, no matter the build system, what we want is a way
to guide users to a proper DPDK installation.
Your solution is to add some very specific logs.
My proposal is to guide the user with a script and some
specific parameters so it will fail if a required dependency is not met.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 17:05         ` Thomas Monjalon
@ 2019-05-24 17:11           ` Stephen Hemminger
  2019-05-24 17:32             ` Thomas Monjalon
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-24 17:11 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

On Fri, 24 May 2019 19:05:20 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> > > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > > so that doesn't help.
> > > > 
> > > > This is a warning and not fatal only because application will still at
> > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > > 
> > > > 
> > > > The warning is just to give users better immediate feedback rather than
> > > > trying to diagnose poor performance or mystery device not found messages.    
> > > 
> > > 
> > > It really looks strange to me.
> > > What you need is to fail at compilation if requested PMD is not built.
> > > I would advise to work on a script to configure meson.  
> > 
> > None of the people that ran into this were using meson build.
> > For example, VPP doesn't use meson.  
> 
> They will use meson when makefile will be removed :)
> 
> Anyway, no matter the build system, what we want is a way
> to guide users to a proper DPDK installation.
> Your solution is to add some very specific logs.
> My proposal is to guide the user with a script and some
> specific parameters so it will fail if a required dependency is not met.

Not familiar enough with meson magic syntax to make vdev_netvsc not build
without MLX. But that would just be pushing the mystery failure further
down the road.

Another alternative would be to drop vdev_netvsc from the default Linux
build. That way users would have to enable it manually.

My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD
but that is a couple releases away.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 17:11           ` Stephen Hemminger
@ 2019-05-24 17:32             ` Thomas Monjalon
  2019-05-24 22:06               ` Stephen Hemminger
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2019-05-24 17:32 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

24/05/2019 19:11, Stephen Hemminger:
> On Fri, 24 May 2019 19:05:20 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > > > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > > > so that doesn't help.
> > > > > 
> > > > > This is a warning and not fatal only because application will still at
> > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > > > 
> > > > > 
> > > > > The warning is just to give users better immediate feedback rather than
> > > > > trying to diagnose poor performance or mystery device not found messages.    
> > > > 
> > > > 
> > > > It really looks strange to me.
> > > > What you need is to fail at compilation if requested PMD is not built.
> > > > I would advise to work on a script to configure meson.  
> > > 
> > > None of the people that ran into this were using meson build.
> > > For example, VPP doesn't use meson.  
> > 
> > They will use meson when makefile will be removed :)
> > 
> > Anyway, no matter the build system, what we want is a way
> > to guide users to a proper DPDK installation.
> > Your solution is to add some very specific logs.
> > My proposal is to guide the user with a script and some
> > specific parameters so it will fail if a required dependency is not met.
> 
> Not familiar enough with meson magic syntax to make vdev_netvsc not build
> without MLX. But that would just be pushing the mystery failure further
> down the road.

I think you did not understand my proposal.
Let's take an example. You give this instruction to build DPDK:
	buildtools/build-require.sh vdev_netvsc mlx4
If mlx4 is not built then it will fail with this message:
	librte_pmd_mlx4 failed to build
So the user knows what went wrong. No mystery.


> Another alternative would be to drop vdev_netvsc from the default Linux
> build. That way users would have to enable it manually.
> 
> My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD
> but that is a couple releases away.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 17:32             ` Thomas Monjalon
@ 2019-05-24 22:06               ` Stephen Hemminger
  2019-05-27  8:31                 ` Thomas Monjalon
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-24 22:06 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

On Fri, 24 May 2019 19:32:14 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 24/05/2019 19:11, Stephen Hemminger:
> > On Fri, 24 May 2019 19:05:20 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >   
> > > > > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > > > > so that doesn't help.
> > > > > > 
> > > > > > This is a warning and not fatal only because application will still at
> > > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > > > > 
> > > > > > 
> > > > > > The warning is just to give users better immediate feedback rather than
> > > > > > trying to diagnose poor performance or mystery device not found messages.      
> > > > > 
> > > > > 
> > > > > It really looks strange to me.
> > > > > What you need is to fail at compilation if requested PMD is not built.
> > > > > I would advise to work on a script to configure meson.    
> > > > 
> > > > None of the people that ran into this were using meson build.
> > > > For example, VPP doesn't use meson.    
> > > 
> > > They will use meson when makefile will be removed :)
> > > 
> > > Anyway, no matter the build system, what we want is a way
> > > to guide users to a proper DPDK installation.
> > > Your solution is to add some very specific logs.
> > > My proposal is to guide the user with a script and some
> > > specific parameters so it will fail if a required dependency is not met.  
> > 
> > Not familiar enough with meson magic syntax to make vdev_netvsc not build
> > without MLX. But that would just be pushing the mystery failure further
> > down the road.  
> 
> I think you did not understand my proposal.
> Let's take an example. You give this instruction to build DPDK:
> 	buildtools/build-require.sh vdev_netvsc mlx4

There is no build-require.sh now and introducing yet another tool
is not going to help.

> If mlx4 is not built then it will fail with this message:
> 	librte_pmd_mlx4 failed to build
> So the user knows what went wrong. No mystery.
> 
> 
> > Another alternative would be to drop vdev_netvsc from the default Linux
> > build. That way users would have to enable it manually.
> > 
> > My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD
> > but that is a couple releases away.  

Let's just fix the meson.build for now to skip vdev_netvsc unless both mlx4 and mlx5 are present.

The Makefile can just remain untouched.
The people with problem are on older releases anyway. So any attempt to fix
the Makefiles won't help those on 18.02, etc.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-24 22:06               ` Stephen Hemminger
@ 2019-05-27  8:31                 ` Thomas Monjalon
  2019-05-27 14:54                   ` Stephen Hemminger
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2019-05-27  8:31 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

25/05/2019 00:06, Stephen Hemminger:
> On Fri, 24 May 2019 19:32:14 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> > 24/05/2019 19:11, Stephen Hemminger:
> > > On Fri, 24 May 2019 19:05:20 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >   
> > > > > > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > > > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > > > > > so that doesn't help.
> > > > > > > 
> > > > > > > This is a warning and not fatal only because application will still at
> > > > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > > > > > 
> > > > > > > 
> > > > > > > The warning is just to give users better immediate feedback rather than
> > > > > > > trying to diagnose poor performance or mystery device not found messages.      
> > > > > > 
> > > > > > 
> > > > > > It really looks strange to me.
> > > > > > What you need is to fail at compilation if requested PMD is not built.
> > > > > > I would advise to work on a script to configure meson.    
> > > > > 
> > > > > None of the people that ran into this were using meson build.
> > > > > For example, VPP doesn't use meson.    
> > > > 
> > > > They will use meson when makefile will be removed :)
> > > > 
> > > > Anyway, no matter the build system, what we want is a way
> > > > to guide users to a proper DPDK installation.
> > > > Your solution is to add some very specific logs.
> > > > My proposal is to guide the user with a script and some
> > > > specific parameters so it will fail if a required dependency is not met.  
> > > 
> > > Not familiar enough with meson magic syntax to make vdev_netvsc not build
> > > without MLX. But that would just be pushing the mystery failure further
> > > down the road.  
> > 
> > I think you did not understand my proposal.
> > Let's take an example. You give this instruction to build DPDK:
> > 	buildtools/build-require.sh vdev_netvsc mlx4
> 
> There is no build-require.sh now and introducing yet another tool
> is not going to help.

I disagree.
I think we are missing this tool.

> > If mlx4 is not built then it will fail with this message:
> > 	librte_pmd_mlx4 failed to build
> > So the user knows what went wrong. No mystery.
> > 
> > 
> > > Another alternative would be to drop vdev_netvsc from the default Linux
> > > build. That way users would have to enable it manually.
> > > 
> > > My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD
> > > but that is a couple releases away.  
> 
> Let's just fix the meson.build for now to skip vdev_netvsc unless both mlx4 and mlx5 are present.

This is not a fix but a hack.
Why vdev_netvsc would need mlx PMDs? Because it is the Azure config?

> The Makefile can just remain untouched.
> The people with problem are on older releases anyway. So any attempt to fix
> the Makefiles won't help those on 18.02, etc.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
  2019-05-27  8:31                 ` Thomas Monjalon
@ 2019-05-27 14:54                   ` Stephen Hemminger
  0 siblings, 0 replies; 11+ messages in thread
From: Stephen Hemminger @ 2019-05-27 14:54 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, matan, Stephen Hemminger

On Mon, 27 May 2019 10:31:22 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 25/05/2019 00:06, Stephen Hemminger:
> > On Fri, 24 May 2019 19:32:14 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:  
> > > 24/05/2019 19:11, Stephen Hemminger:  
> > > > On Fri, 24 May 2019 19:05:20 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >     
> > > > > > > > device drivers on Hyper-V/Azure.  If the build system supported dependencies
> > > > > > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies
> > > > > > > > so that doesn't help.
> > > > > > > > 
> > > > > > > > This is a warning and not fatal only because application will still at
> > > > > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > The warning is just to give users better immediate feedback rather than
> > > > > > > > trying to diagnose poor performance or mystery device not found messages.        
> > > > > > > 
> > > > > > > 
> > > > > > > It really looks strange to me.
> > > > > > > What you need is to fail at compilation if requested PMD is not built.
> > > > > > > I would advise to work on a script to configure meson.      
> > > > > > 
> > > > > > None of the people that ran into this were using meson build.
> > > > > > For example, VPP doesn't use meson.      
> > > > > 
> > > > > They will use meson when makefile will be removed :)
> > > > > 
> > > > > Anyway, no matter the build system, what we want is a way
> > > > > to guide users to a proper DPDK installation.
> > > > > Your solution is to add some very specific logs.
> > > > > My proposal is to guide the user with a script and some
> > > > > specific parameters so it will fail if a required dependency is not met.    
> > > > 
> > > > Not familiar enough with meson magic syntax to make vdev_netvsc not build
> > > > without MLX. But that would just be pushing the mystery failure further
> > > > down the road.    
> > > 
> > > I think you did not understand my proposal.
> > > Let's take an example. You give this instruction to build DPDK:
> > > 	buildtools/build-require.sh vdev_netvsc mlx4  
> > 
> > There is no build-require.sh now and introducing yet another tool
> > is not going to help.  
> 
> I disagree.
> I think we are missing this tool.
> 
> > > If mlx4 is not built then it will fail with this message:
> > > 	librte_pmd_mlx4 failed to build
> > > So the user knows what went wrong. No mystery.
> > > 
> > >   
> > > > Another alternative would be to drop vdev_netvsc from the default Linux
> > > > build. That way users would have to enable it manually.
> > > > 
> > > > My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD
> > > > but that is a couple releases away.    
> > 
> > Let's just fix the meson.build for now to skip vdev_netvsc unless both mlx4 and mlx5 are present.  
> 
> This is not a fix but a hack.
> Why vdev_netvsc would need mlx PMDs? Because it is the Azure config?

MLX is required because no other VF device has been tested. Intel devices barely work
(wrong PCI id, and only a single queue). No one has ever tried other vendors.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-05-27 14:54 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-23 22:01 [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured Stephen Hemminger
2019-05-24 13:26 ` Ferruh Yigit
2019-05-24 16:07   ` Stephen Hemminger
2019-05-24 16:38     ` Thomas Monjalon
2019-05-24 16:48       ` Stephen Hemminger
2019-05-24 17:05         ` Thomas Monjalon
2019-05-24 17:11           ` Stephen Hemminger
2019-05-24 17:32             ` Thomas Monjalon
2019-05-24 22:06               ` Stephen Hemminger
2019-05-27  8:31                 ` Thomas Monjalon
2019-05-27 14:54                   ` Stephen Hemminger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.