From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
dev@dpdk.org, Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [dpdk-dev] [PATCH 1/5] bus/vmbus: add devargs support
Date: Fri, 14 Sep 2018 15:58:04 +0200 [thread overview]
Message-ID: <20180914135804.qhvusuub4kdqrhpz@bidouze.vm.6wind.com> (raw)
In-Reply-To: <ee484512-d8a8-fe6c-67ab-b17f633d2ac8@intel.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
next prev parent reply other threads:[~2018-09-14 13:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 22:35 [dpdk-dev] [PATCH 0/5] netvsc changes for 18.11 Stephen Hemminger
2018-08-30 22:35 ` [dpdk-dev] [PATCH 1/5] bus/vmbus: add devargs support Stephen Hemminger
2018-09-14 12:46 ` Ferruh Yigit
2018-09-14 13:06 ` Gaëtan Rivet
2018-09-14 13:19 ` Ferruh Yigit
2018-09-14 13:58 ` Gaëtan Rivet [this message]
2018-09-14 15:21 ` Stephen Hemminger
2018-08-30 22:35 ` [dpdk-dev] [PATCH 2/5] net/netvsc: allow tuning latency with devargs Stephen Hemminger
2018-09-14 12:47 ` Ferruh Yigit
2018-08-30 22:35 ` [dpdk-dev] [PATCH 3/5] net/netvsc: exhausting transmit descriptors is not an error Stephen Hemminger
2018-08-30 22:35 ` [dpdk-dev] [PATCH 4/5] net/netvsc: implement link state change callback Stephen Hemminger
2018-08-31 8:25 ` Gaëtan Rivet
2018-08-31 15:13 ` Stephen Hemminger
2018-08-30 22:35 ` [dpdk-dev] [PATCH 5/5] net/netvsc: integrated VF support Stephen Hemminger
2018-09-14 12:57 ` Ferruh Yigit
2018-09-14 15:22 ` Stephen Hemminger
2018-08-31 12:04 ` [dpdk-dev] [PATCH 0/5] netvsc changes for 18.11 Ferruh Yigit
2018-08-31 15:15 ` Stephen Hemminger
2018-08-31 16:56 ` Thomas Monjalon
2018-09-14 13:25 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180914135804.qhvusuub4kdqrhpz@bidouze.vm.6wind.com \
--to=gaetan.rivet@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=stephen@networkplumber.org \
--cc=sthemmin@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).