From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7E42AA04FF; Tue, 24 May 2022 12:15:22 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2AC0940140; Tue, 24 May 2022 12:15:22 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 16BE8400D6 for ; Tue, 24 May 2022 12:15:20 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EAEA43200971; Tue, 24 May 2022 06:15:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 24 May 2022 06:15:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653387316; x= 1653473716; bh=YTWK5RAaIuvH+Aq6w3PXhRWtDx1COeboWT1o2ycxLB4=; b=c ILKRZjgJaPEfVYo529RKhiI8p04/SmiwAwwUYn8kufBvk0wFLjfleXox9oL7VvD4 XLv1ViCp6kOummAhOa3AWHXNZvYgRrtPweCviBLry/Oda54CtOZsjQ9SRloq6UlH KezYrtWv1+Hu9IIaNQpBajRmzOc3FFh7osk0RK0XR5rCEzCZkwYXQJc10IBdool4 MQ0hV5ayPfN7YLQ4BIRXq5hdybWpndxjLQbgUTZlyHHrz+1K7DZIFjIEmSVfe/AY Nfr50O5o9RCOiDLrUrQleGm80yLi6LtMC6+jSE4Yk7K6nYtBwUURiKMCAKo/nmnU sEVSohMLk1y52OybVnzTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653387316; x= 1653473716; bh=YTWK5RAaIuvH+Aq6w3PXhRWtDx1COeboWT1o2ycxLB4=; b=O 2HPMS9L/9GBPavK4bxu9StAVi/tVmlAmicDveOWMeSk3ULKvNyXEYv/Q8ZKZpvNr ZrQe01OPLPT5vlMe05vuKyguH5ws2/fm2dX90bDXD3E+ind480TP9bNti197WReV cHgjjI89QDC/Eff2e2X7y9qTxHYZNEBSDBKpb4kmgSQAEu3q6fkGpuNRgUVxqXxI AvQB46+L5VDp3kAMYJG8yPgaacSBLMRWybFWXqKZnR27FZHvg+4VqfgSya4Qzsex 5O9OS0cHBa1+HArGnEw7j3oex6rXoeUUzeMAlzAc4xstjucPpIb6b/NOLtA3tU00 DeogzBy8/8wmcy1UnWuPg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjeefgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdtuefhhedvkeelleevffdvlefhleehvdegtddvvdduueeivedt gfejvddugeefnecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 May 2022 06:15:13 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , David Marchand , Konstantin Ananyev Cc: dev@dpdk.org, "Min Hu (Connor)" , Xiaoyun Li , Aman Singh , Yuying Zhang , Chas Williams , jerinj@marvell.com Subject: Re: [RFC PATCH 2/4] net/bonding: move testpmd commands Date: Tue, 24 May 2022 12:15:06 +0200 Message-ID: <8524011.OUTRe80PYV@thomas> In-Reply-To: References: <20220513075718.18674-1-david.marchand@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 24/05/2022 11:40, Konstantin Ananyev: > 20/05/2022 07:59, Andrew Rybchenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On 5/19/22 14:26, Thomas Monjalon wrote: > >> 19/05/2022 09:40, David Marchand: > >>> On Thu, May 19, 2022 at 1:25 AM Konstantin Ananyev > >>> wrote: > >>>> 18/05/2022 18:24, David Marchand =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>> On Fri, May 13, 2022 at 12:10 PM Min Hu (Connor)=20 > >>>>> wrote: > >>>>>> > >>>>>> I think net/bonding offer 'API' for APP to use the bonding. > >>>>>> and use the specific PMD as slave device. > >>>>>> The software framwork is like: > >>>>>> APP > >>>>>> ethdev > >>>>>> bonding PMD > >>>>>> PMD > >>>>>> hardware > >>>>>> > >>>>>> so, I think cmdlines for testpmd should not put in net/bonding.be > >> > >> The bonding API is specific to drivers/net/bonding/, > >> so according to the techboard decision, > >> the testpmd code should go in the driver directory. > >=20 > > +1 > >=20 > >> > >>>> Actually, I feel the same. > >>>> I do understand the intention, and I do realize it is just location, > >>>> but still doesn't look right for me. > >>>> can't we have a special sub-folder in testpmd instead? > >>>> Something like app/testpmd/driver_specific/(ixgbe)|(i40e)|(bonding).= =2E. > >>> > >>> That should not pose a problem, indeed. > >>> And, on the plus side, it avoids putting some testpmd global variables > >>> in meson (which I was not entirely happy with). > >> > >> I like the global variables approach. > >=20 > > +1 > >=20 > >> > >>> But, on the other side, I have a concern about MAINTAINERS updates. > >>> > >>> (almost) everything in app/test-pmd has been under the testpmd > >>> maintainer responsibility. > >>> Separating the driver specific code from testpmd is a way to clearly > >>> shift this responsibility to the driver maintenance. > >> > >> I agree. > >=20 > > +1 > >=20 > >> > >>> One advantage of moving the code to the driver directory is that there > >>> is no MAINTAINERS update needed. > >> > >> Yes I think moving test code in the driver directory is smart. > >> We already have this approach for some self tests run with app/test. > >> And more important, the techboard has decided to move code in the driv= er > >> or lib directory: > >> https://mails.dpdk.org/archives/dev/2022-April/239191.html >=20 > Yep, I remember that discussion, though from my impression > (probably wrong) people talked more about need for some smart > testpmd plugin approach. > I didn't realize that it would mean literally dump all > current cmd-line related code straight into drivers/net. > I agree that testpmd code for PMD-specific API should be > responsibility of this PMD maintainer. > I just don't feel that drivers/net is the best place for it. > As another thing to consider: what would happen if we'll decide > to rework testpmd interface (from CLI to gRPC or so), or introduce > new app for PMD testing - would we need to inject all these things > into drivers/net too? Yes I think it's OK to have driver-specific test code in the driver directory. This is what is already done for eventdev and rawdev drivers: git ls-files drivers | grep test