Re: [dpdk-dev] [PATCH 1/5] bus/vmbus: add devargs support

["Gaëtan Rivet" <gaetan.rivet@6wind.com>]

On Fri, Sep 14, 2018 at 02:19:19PM +0100, Ferruh Yigit wrote:
> On 9/14/2018 2:06 PM, Gaëtan Rivet wrote:
> > Hi,
> > 
> > On Fri, Sep 14, 2018 at 01:46:59PM +0100, Ferruh Yigit wrote:
> >> On 8/30/2018 11:35 PM, Stephen Hemminger wrote:
> >>> From: Stephen Hemminger <sthemmin@microsoft.com>
> >>>
> >>> Take device arguments from command line and put
> >>> them in the device devargs.
> >>>
> >>> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> >>
> >> <...>
> >>
> >>> @@ -204,6 +203,27 @@ vmbus_parse(const char *name, void *addr)
> >>>  	return ret;
> >>>  }
> >>>  
> >>> +/*
> >>> + * scan for matching device args on command line
> >>> + * example:
> >>> + *	-w 'vmbus(635a7ae3-091e-4410-ad59-667c4f8c04c3,latency=20)'
> >>
> >> This is just in comment but,
> >>
> >> I guess latest syntax is:
> >>  -w "vmbus:635a7ae3-091e-4410-ad59-667c4f8c04c3,latency=20"
> >>
> >> @Gaetan, is latest devarg syntax documented somewhere?
> > 
> > That's the current syntax indeed. Some documentation is found at
> > 
> > lib/librte_eal/common/include/rte_devargs.h:100
> > 
> > Where it is specified that the bus name can be either omitted or
> > followed by any character, to separate it from the device identifier.
> > 
> > This means that using ':' is fine, as well as '('. As long as the device
> > PMD afterward ignore the dangling ')' during devargs parsing, this should
> > be fine.
> > 
> > I don't think this is very clean, but it works.
> 
> Thanks for the info, I see how "(" works, but ")" is takes as part of argument
> and causing problem, I think better to not give "()" as supported syntax at all.
> 
> btw, now both -w and --vdev are valid and can be used interchangeably, right? I
> mean all following are valid?
> -w pci:0000:86:06.0,enable_floating_veb=1
> -w vdev:net_pcap,iface=lo
> --vdev pci:0000:86:06.0,enable_floating_veb=1
> --vdev vdev:net_pcap,iface=lo
> 
> 

They are both valid but cannot be used interchangeably.

This was the case at one point, between two rcs, because I had removed
the devtype and the bus black/white-listing was configured another way.

A user complained about the API change because it was not announced in
time IIRC, and this was scrapped. Since then, the effort has been to on
the new syntax instead of cleaning the old system.

They cannot be used interchangeably because an rte_devtype is defined by
the parameter choosen. BLACKLISTED_PCI for -b, WHITELISTED_PCI for -w,
and VIRTUAL for --vdev.

-b will actually change the bus configuration to "blacklist mode", -w to
"whitelist mode", and --vdev will do nothing.

So a PCI device declared using --vdev, will actually be skipped during
PCI probe because by default it operates in blacklist mode, and the
device policy is not WHITELISTED. This could surprise the one attempting
this trick.

This semantic is subtle and bug-prone. I'm adding it to the pile of
reasons I'd like to remove the blacklist mode altogether.

-- 
Gaëtan Rivet
6WIND