From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v2 12/18] eal: add generic device declaration parameter Date: Wed, 13 Dec 2017 15:47:04 +0100 Message-ID: <20171213144704.4d7675gw7iaasvtb@bidouze.vm.6wind.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org To: Shreyansh Jain Return-path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 95BBD2030 for ; Wed, 13 Dec 2017 15:47:17 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id y82so22101466wmg.1 for ; Wed, 13 Dec 2017 06:47:17 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Dec 13, 2017 at 07:56:42PM +0530, Shreyansh Jain wrote: > On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote: > > Add a new generic device declaration parameter: > > > > --dev= > > > > [...] > > > > > diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c > > index 603df27..b7591fd 100644 > > --- a/lib/librte_eal/common/eal_common_options.c > > +++ b/lib/librte_eal/common/eal_common_options.c > > @@ -95,6 +95,7 @@ eal_long_options[] = { > > {OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM }, > > {OPT_SOCKET_MEM, 1, NULL, OPT_SOCKET_MEM_NUM }, > > {OPT_SYSLOG, 1, NULL, OPT_SYSLOG_NUM }, > > + {OPT_DEV, 1, NULL, OPT_DEV_NUM }, > > {OPT_VDEV, 1, NULL, OPT_VDEV_NUM }, > > {OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM }, > > {OPT_VMWARE_TSC_MAP, 0, NULL, OPT_VMWARE_TSC_MAP_NUM }, > > @@ -1120,6 +1121,21 @@ eal_parse_common_option(int opt, const char *optarg, > > } > > break; > > + case OPT_DEV_NUM: { > > + struct rte_devargs da; > > + int ret; > > + > > + if (rte_eal_devargs_parse(&da, optarg) < 0) > > + return -1; > > + ret = rte_bus_probe_mode_set(da.bus->name, > > + RTE_BUS_PROBE_WHITELIST); > > + if (ret < 0 && ret != -ENOTSUP) > > + return -1; > > + if (eal_option_device_add(NULL, optarg) < 0) > > + return -1; > > + } > > Might be a naive question: Any specific reason why we don't add the devices > directly into devargs_list here (eal_parse_args -> eal_parse_common_option > -> OPT_DEV ->) rather than wait for eal to call eal_option_device_parse > again? > > Is it to allow eal_plugins_init() to finish? > Yes. And actually this makes me aware of an issue with this implementation. Calling rte_eal_devargs_parse here is premature, and rte_bus_probe_mode_set as well. eal_plugins_init() must be executed before calling rte_devargs to allow for buses introduced as plugins to be able to recognize their devices. I will reorder a few things in eal_options, thanks for catching this. > > + break; > > + > > case OPT_VDEV_NUM: > > if (eal_option_device_add("vdev", optarg) < 0) > > return -1; > > [...] > -- Gaëtan Rivet 6WIND