From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A30548D3C for ; Thu, 26 Apr 2018 16:44:36 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4B69420EC0; Thu, 26 Apr 2018 10:44:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 26 Apr 2018 10:44:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=PJutX4rkenRTPpxhyAkN4XozHN mPTog6pVk0UMfIQ5I=; b=P+3JqC6v7rmv1NQtO4a/Xusw9B6iu4TllZUS2uWqea U1OSfj99nJ7awOsEaQzkaDKSb8SvF8GkO9DSvuT3/B5pTrCSk7V347QIRUM8apKL FpqNo3VlPv7IUI98xCFF8Zqjza6tyuQ6fSKjLEXCv/Al8yx9cYqbZUHfebqMuAzT I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=PJutX4 rkenRTPpxhyAkN4XozHNmPTog6pVk0UMfIQ5I=; b=h+7kNuL/IIjzGOXBkc2Ti8 z1jlhC+p7vbZPdPsg+zgVCgJBMbdhPiA0ae/NnhS/QOQnTO31ErLONwDezTkgREu 7DwbI3+ueHcHahFyVWbUK5f1Ud/p1Uyjx9A7UtMHonrlfC2/rx3Xi7kAoCWTMQyk CENNWLpS11dehXVNjN+UfWt4GIIeg+sj45ORY6FfmbPRXURRaLLWOgDUDNiEn4O7 3tpJJXzalMOOUN9iV6o9R1Um47UihOUM6vAO1P61AqU44JL2shz6Ku2xAoW/RynI MpvwL3FL/LuuzuuKi1SUVQv9IMJCn0nBTEbM/3L1QoUKXc4n+iuvm4cqX41sMi3g == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 1CCDAE47A0; Thu, 26 Apr 2018 10:44:35 -0400 (EDT) From: Thomas Monjalon To: "Doherty, Declan" Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , Adrien Mazarguil , "Yigit, Ferruh" , Shahaf Shuler , "Horton, Remy" , gaetan.rivet@6wind.com Date: Thu, 26 Apr 2018 16:44:33 +0200 Message-ID: <1766858.7hL0hTjUtK@xps> In-Reply-To: <6c84cc1c-9ad4-11e5-f99f-1bc7152c7b14@intel.com> References: <20180416130605.6509-1-declan.doherty@intel.com> <2601191342CEEE43887BDE71AB977258AEBD049D@IRSMSX102.ger.corp.intel.com> <6c84cc1c-9ad4-11e5-f99f-1bc7152c7b14@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 14:44:37 -0000 26/04/2018 16:28, Doherty, Declan: > On 26/04/2018 1:03 PM, Ananyev, Konstantin wrote: > > From: Doherty, Declan > >> +typedef int (*rte_eth_devargs_callback_t)(char *str, void *data); > >> + > >> +static int > >> +rte_eth_devargs_tokenise(struct rte_kvargs *arglist, const char *str_in) > >> +{ > > > > 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? > > > > As an alternative - as I remember rte_kvargs allows you to have multiple identical key, i.e: "key=val1,key=val2,...,key=valn". > > Why not to use that way, if you don't want to introduce extra code in rte_kvargs? > > > > Hey Konstantin, the rationale for keeping this independent from > librte_kvargs was that it is likely that the implementation of parsing > devarfs will change in the next release due the proposed rework on the > whole devargs infrastructure. I hadn't considered the potential issue > with rte_kvargs_parse() on string using the proposed syntax here. I'll > send a patch for alignment with librte_kvargs for the next release > candidate. The new devargs infra will rely on librte_kvargs. So improving kvargs is the right way here.