From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 9C6CF374 for <dev@dpdk.org>; Wed, 21 Jun 2017 14:14:34 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5402F20A37; Wed, 21 Jun 2017 08:14:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 21 Jun 2017 08:14:34 -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:x-sasl-enc; s=mesmtp; bh=HRlG/QnQWsefDYC 4cjvxkN8D2PIT8g7upYNuzRWgSjU=; b=rw2gNxEsGAETLwac1oIum9cDHCvYIQ2 tqZLIKj5EiBJVYYZXiIrj2ywGzY8OzGWWw25YKjy7/1UIJPiJ4XVcfvuquImXOO9 sg7Mp3ONDxMdiJ/kQo7xt0PCLTWXmkuxPhYSFoN6Duo3wq2Cbw3Hcr3Ia4f1xs78 9v6NO/whn00k= 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:x-sasl-enc; s= fm1; bh=HRlG/QnQWsefDYC4cjvxkN8D2PIT8g7upYNuzRWgSjU=; b=ZEBdFrzL jVpI5xQkp2T5h9earVWfB+OJh6t0avBBq3pcVobJgEZw1sb5I8vE1fyTW8wcEKoF gHplBDipnQEVg4ncJz4sTcmSDnR2zQii4fup33+buQYIT1QNM1XU8WIwedzKmkw7 EIWfodioeOrbpMJhg4q/FLg+4XA1KqQpA62EbQQ+IEgp10Ypmws3ema6nISKsY4+ BqgjO0nDugU+2SQCY/5TJCT5OXGsMzliWri/8M80Z8zHrSHzZkWIoWhOqJoazXyY z1bt76oRP8wKpvvf1DWR1WYSBJraiAKY3KfoAsJyBS+bCnSd08yhGeX6cplQGxoU zYPgbxgGm0Agpw== X-ME-Sender: <xms:KmNKWff7qd7py1UocsIvBKH_Zz-txCI4YyQDQ1P2_GCOekZMBb-dgA> X-Sasl-enc: vo/8uwVPR+bNe2Qg9D+8mpZLbqcsomBbYL4JkZ5DBedE 1498047274 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C09324234; Wed, 21 Jun 2017 08:14:34 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> Cc: dev@dpdk.org Date: Wed, 21 Jun 2017 14:14:33 +0200 Message-ID: <2497445.pUfxcqGo6k@xps> In-Reply-To: <20170621113929.GE2344@bidouze.vm.6wind.com> References: <cover.1496877060.git.gaetan.rivet@6wind.com> <10937675.k8W90Yh6uJ@xps> <20170621113929.GE2344@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH v3 5/9] pmdinfogen: move to drivers subdirectory X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 21 Jun 2017 12:14:35 -0000 21/06/2017 13:39, Ga=EBtan Rivet: > On Wed, Jun 21, 2017 at 12:00:24PM +0200, Thomas Monjalon wrote: > > 21/06/2017 11:40, Ga=EBtan Rivet: > > > On Wed, Jun 21, 2017 at 09:57:18AM +0200, Thomas Monjalon wrote: > > > > Another (probably better) solution is to keep basic definitions > > > > and helpers in EAL: > > > > - rte_pci.h keeps only some PCI definitions and helpers > > > > like rte_pci_addr and eal_parse_pci_BDF() in EAL > > > > - bus management is done in the PCI driver > > > >=20 > > > > For pmdinfogen, we just need struct rte_pci_id. > > > > Other tools or applications will probably need this kind of basic > > > > struct and functions available in EAL. > > >=20 > > > I mostly agree, this proposal should be kept to a minimum at first for > > > this release and carefully expanded afterward. > > >=20 > > > If that's ok, I will propose a new version of this patchset with a new > > > librte_pci, that might fix both pmdinfogen and librte_kni. > >=20 > > Why creating a new librte_pci instead of just keeping it in EAL? >=20 > While I agree that it makes sense to have PCI helpers shared among > several subsystems, I do not see a reason for the EAL to rely on it. >=20 > The EAL is the bedrock of the whole system. Having those helpers within > would mean that one expects them to be used to build this bedrock. It > would be misleading. >=20 > In the context of a framework, aimed at being used by others, an okay > architecture is one that works. A good architecture is one that > intrinsically convey meaning and explains its goal to developers relying > on it. I think that having this PCI lib within EAL just because nothing > prevents us from doing so is mistaken, in this regard. >=20 > Conversely, the argument about being conservative in the changes, > especially to an essential part such as the EAL, is obsolete for this > release and this subsystem, as deep changes are necessary anyway, > and the design should be right from the get go to allow further stability. >=20 > Finally, the PCI lib and bus is also an example for other developers. I > do not think that all other hardware buses should be allowed in adding > their own specific helpers to the EAL. In this regard, there is no > reason to have an exception made just for the PCI lib. You get a point :)