From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=2PiU8fycQhW7y/4Z6FF8r582VVMl8v4pnAwT+TByIQg=; b=JEeSv/CU+EC+Qzh1cecG02fXxJb9FDrrAlv3oJOCnzbulLXlnZoe3jPTvrTPMoOZ9i VzcsNMI9nM2d1qXG/S/H2Dx6NP6IWvXUpFtoUXohXGY3VZSxoJgNORvK/2e/pnv6fbBO zzkc0g7icMOnL17UiZ6HxdBpvrc6pVpKqj2B9DGTA0cmI/MwUlMXwX8ChM0+HdBBQG56 CZYX6BP56jPzh0izmsuDm59y+ewrxDpbFukXx871hJSiqXc6Yq+YvtFPDKW0VLnq6xN/ K+Rq2lxuuFzTQbWXWMiMTDk/hrZPIJXtzxFT7kFtxS2QaMVRar8WsRQYj3treKi6eZWg fUCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=2PiU8fycQhW7y/4Z6FF8r582VVMl8v4pnAwT+TByIQg=; b=LMOouKiZYWQS4TRhI8UYf9uTGNXBaxXzaQpisqCyqvITmB+NyJOdRDPpJA6+cvRk7e lYyFQ1IO7BMNsAa/jlRpKLzKOPaYMb1fcOknMZw54xh3GmbtY9N2ZZu1BYywEAWrvL40 R409iuuwY9ktmD1ycU0nsmm1Aca2zQyH2hn+LtkW70mRhJIVZn09jFn9yrGXI0kubadm TuUY+0sFL7a+kxnQw4TrDD8X6e7bIsbiVQa+2Zq4cCG9+Isi3AEYXpGOuMEoCxCfpDoK +Yt882vZqDFwzXHmUlkOT3RYVdqSrSv5Vn8E8ci/+i6Guqtl2DUJnNYAN16vwB/opvBl suHg== X-Gm-Message-State: AElRT7HatNHloOpBBvAp1H8002fZEG+CZJJOsLTMe55t27R76bJXaX7w 6In9OdTTcFiRsRVuQir+zj3NUA== X-Google-Smtp-Source: AIpwx49wO/1gSvzr4L/nZ8Dd2+6JRRT6xu9iOattc/iY+qhLiizle694qg7vmYkTBz0DykBVgzQ2DQ== X-Received: by 10.223.177.145 with SMTP id q17mr6331829wra.26.1522325585190; Thu, 29 Mar 2018 05:13:05 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id r126sm2929089wmb.10.2018.03.29.05.13.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Mar 2018 05:13:04 -0700 (PDT) Date: Thu, 29 Mar 2018 14:12:50 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Declan Doherty Cc: dev@dpdk.org, Ferruh Yigit , Thomas Monjalon , Mohammad Abdul Awal , Remy Horton , Yuanhan Liu 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180328135433.20203-7-declan.doherty@intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v6 6/8] ethdev: add common devargs parser X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 12:13:05 -0000 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