[dpdk-dev] [PATCH v3 6/8] net/vdev_netvsc: skip routed netvsc probing

[Matan Azrad]

Hi Stephan

From: Stephen Hemminger, Wednesday, January 10, 2018 6:44 PM
> On Wed, 10 Jan 2018 15:07:14 +0000
> Matan Azrad <matan at mellanox.com> wrote:
> 
> > Hi Stephan
> >
> > From: Stephen Hemminger, Tuesday, January 9, 2018 8:51 PM
> > > To: Matan Azrad <matan at mellanox.com>
> > > Cc: Ferruh Yigit <ferruh.yigit at intel.com>; Thomas Monjalon
> > > <thomas at monjalon.net>; dev at dpdk.org; Raslan Darawsheh
> > > <rasland at mellanox.com>
> > > Subject: Re: [PATCH v3 6/8] net/vdev_netvsc: skip routed netvsc
> > > probing
> > >
> > > On Tue,  9 Jan 2018 14:47:31 +0000
> > > Matan Azrad <matan at mellanox.com> wrote:
> > >
> > > > NetVSC netdevices which are already routed should not be probed
> > > > because they are used for management purposes by the HyperV.
> > > >
> > > > prevent routed netvsc devices probing.
> > > >
> > > > Signed-off-by: Raslan Darawsheh <rasland at mellanox.com>
> > > > Signed-off-by: Matan Azrad <matan at mellanox.com>
> > > > ---
> > > >  doc/guides/nics/vdev_netvsc.rst       |  2 +-
> > > >  drivers/net/vdev_netvsc/vdev_netvsc.c | 46
> > > > +++++++++++++++++++++++++++++++++++
> > > >  2 files changed, 47 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/doc/guides/nics/vdev_netvsc.rst
> > > > b/doc/guides/nics/vdev_netvsc.rst index fde1fb8..f779862 100644
> > > > --- a/doc/guides/nics/vdev_netvsc.rst
> > > > +++ b/doc/guides/nics/vdev_netvsc.rst
> > > > @@ -87,4 +87,4 @@ The following device parameters are supported:
> > > >    MAC address.
> > > >
> > > >  Not specifying either ``iface`` or ``mac`` makes this driver
> > > > attach itself to -all NetVSC interfaces found on the system.
> > > > +all unrouted NetVSC interfaces found on the system.
> > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > index 3d8895b..4295b92 100644
> > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > @@ -38,6 +38,7 @@
> > > >  #define VDEV_NETVSC_PROBE_MS 1000
> > > >
> > > >  #define NETVSC_CLASS_ID "{f8615163-df3e-46c5-913f-f2d2f965ed0e}"
> > > > +#define NETVSC_MAX_ROUTE_LINE_SIZE 300
> > > >
> > > >  #define DRV_LOG(level, ...) \
> > > >  	rte_log(RTE_LOG_ ## level, \
> > > > @@ -192,6 +193,44 @@ static LIST_HEAD(, vdev_netvsc_ctx)
> > > > vdev_netvsc_ctx_list =  }
> > > >
> > > >  /**
> > > > + * Determine if a network interface has a route.
> > > > + *
> > > > + * @param[in] name
> > > > + *   Network device name.
> > > > + *
> > > > + * @return
> > > > + *   A nonzero value when interface has an route. In case of error,
> > > > + *   rte_errno is updated and 0 returned.
> > > > + */
> > > > +static int
> > > > +vdev_netvsc_has_route(const char *name) {
> > > > +	FILE *fp;
> > > > +	int ret = 0;
> > > > +	char route[NETVSC_MAX_ROUTE_LINE_SIZE];
> > > > +	char *netdev;
> > > > +
> > > > +	fp = fopen("/proc/net/route", "r");
> > > > +	if (!fp) {
> > > > +		rte_errno = errno;
> > > > +		return 0;
> > > > +	}
> > > > +	while (fgets(route, NETVSC_MAX_ROUTE_LINE_SIZE, fp) != NULL) {
> > > > +		netdev = strtok(route, "\t");
> > > > +		if (strcmp(netdev, name) == 0) {
> > > > +			ret = 1;
> > > > +			break;
> > > > +		}
> > > > +		/* Move file pointer to the next line. */
> > > > +		while (strchr(route, '\n') == NULL &&
> > > > +		       fgets(route, NETVSC_MAX_ROUTE_LINE_SIZE, fp) !=
> > > NULL)
> > > > +			;
> > > > +	}
> > > > +	fclose(fp);
> > > > +	return ret;
> > > > +}
> > >
> > > In many ways /proc/net/route is legacy intervace.
> > > And system may have 1 M routes.
> > >
> > > Maybe there is faster way to do this with netlink by looking to see
> > > if there is an address associated with the interface.
> >
> > Actually this is control path, we don't care about performance very much.
> > But I can get other idea here, Do you have suggestion?
> >
> > Thanks!
> >
> 
> Use netlink (or ioctl) to get interface address.
> If interface has an IPv4 or IPv6 (not link local), then skip it.

As I a little bit investigated I found that IPv6 getting is problematic by ioctl.
And using nelink for it, really doesn't  worth the effort.
So, I suggest to keep this code simple as is in spite of the optional high latency for this function, after all it is a control path.