From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v6 6/8] ethdev: add common devargs parser Date: Thu, 29 Mar 2018 14:12:50 +0200 Message-ID: <20180329121250.ibbrgpf4m4gyqquy@bidouze.vm.6wind.com> References: <20180328135433.20203-1-declan.doherty@intel.com> <20180328135433.20203-7-declan.doherty@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org, Ferruh Yigit , Thomas Monjalon , Mohammad Abdul Awal , Remy Horton , Yuanhan Liu To: Declan Doherty Return-path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id C99AB231E for ; Thu, 29 Mar 2018 14:13:05 +0200 (CEST) Received: by mail-wr0-f174.google.com with SMTP id o8so5208650wra.1 for ; Thu, 29 Mar 2018 05:13:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20180328135433.20203-7-declan.doherty@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, On Wed, Mar 28, 2018 at 02:54:31PM +0100, Declan Doherty wrote: > From: Remy Horton > > Introduces a new structure, rte_eth_devargs, to support generic > ethdev arguments common across NET PMDs, with a new API > rte_eth_devargs_parse API to support PMD parsing these arguments. > Here is the future layout of rte_devargs: 1. The rte_class introduced by [1], should be expanded with a "find_device" function, equivalent to that of the rte_bus interface. 2. Class and Bus should export a match function as well as a parse function. The match function would be used for device querying, parsing would serve for device declaration. 3. The match function is already implemented by [1]. The parse function for bus already exists and should now be expanded to classes as well. Its expected input should change to be a list of kvargs. 4. Accompanying those changes, the rte_devargs lib would now divide the device string in the three layers identified, use the class parse function to identify the intended class, and be able to feed each layers with its proper input. This way, this API should be generic to all layers. Now, this work in underway but takes time. The current patch I think is an attempt to go in the right direction, but in the end is only a compromise between the simple way and the generic way. Instead of having rte_eth_devargs_parse, you could have had a simple rte_eth_representor_set(uint16_t *pid_list, size_t len); That would have set the proper info within the rte_eth_dev_data. The port_id list would have been parsed by your PMD by reading the representor option. The current version, that feeds directly the devargs to the eth layer, makes conflicts inevitable (with PMDs having potential representor as their parameter, or for future ether parameters such as "mac" that will conflicts with current existing PMD parameters). I would say that this implementation should be simple at first, for the current work on representor. If the generic API is ready for this release, then we might integrate afterward. [1]: https://dpdk.org/ml/archives/dev/2018-March/092891.html > Signed-off-by: Remy Horton > Signed-off-by: Declan Doherty > --- Regards, -- Gaëtan Rivet 6WIND