From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <remy.horton@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 731C87CFF
 for <dev@dpdk.org>; Thu, 26 Apr 2018 16:30:36 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
 by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 26 Apr 2018 07:30:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.49,330,1520924400"; d="scan'208";a="223612696"
Received: from dkahlbac-mobl.ger.corp.intel.com (HELO [10.252.9.25])
 ([10.252.9.25])
 by fmsmga006.fm.intel.com with ESMTP; 26 Apr 2018 07:30:33 -0700
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Doherty, Declan" <declan.doherty@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
References: <20180416130605.6509-1-declan.doherty@intel.com>
 <20180426104105.18342-1-declan.doherty@intel.com>
 <20180426104105.18342-7-declan.doherty@intel.com>
 <2601191342CEEE43887BDE71AB977258AEBD049D@IRSMSX102.ger.corp.intel.com>
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
 "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>, Shahaf Shuler <shahafs@mellanox.com>
From: Remy Horton <remy.horton@intel.com>
Organization: Intel Shannon Limited
Message-ID: <47beac40-7be1-1711-3326-fdc234692b91@intel.com>
Date: Thu, 26 Apr 2018 15:30:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <2601191342CEEE43887BDE71AB977258AEBD049D@IRSMSX102.ger.corp.intel.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v8 6/9] ethdev: add common devargs parser
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2018 14:30:36 -0000


On 26/04/2018 13:03, Ananyev, Konstantin wrote:
[..]
> I still think that if you'd like to extend rte_kvarrgs to be able to parse something like: "key=[val1,val2,...,valn]",
> you have to make it generic kvargs ability and put it into librte_kvargs, not try to introduce your own new parser here.
> Imagine that in addition to your 'port=[val1,val2, ..valn]' devargs string would contain some extra (let say device specific)
> parameters.
> What would happen, when PMD will try to use rte_kvargs_parse() on such string?
> My understanding - it would fail, correct?

This is partly dependent on what will (and won't) devargs provide when 
it is finalised. It was insourced in order to unblock the rest of the 
patchset in the meantime.