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 0C168A0545; Wed, 25 May 2022 00:41:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E12A6400EF; Wed, 25 May 2022 00:41:08 +0200 (CEST) Received: from forward501p.mail.yandex.net (forward501p.mail.yandex.net [77.88.28.111]) by mails.dpdk.org (Postfix) with ESMTP id 46E7C400D6 for ; Wed, 25 May 2022 00:41:07 +0200 (CEST) Received: from vla1-7741ebbbf6f0.qloud-c.yandex.net (vla1-7741ebbbf6f0.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:121a:0:640:7741:ebbb]) by forward501p.mail.yandex.net (Yandex) with ESMTP id B89766212454; Wed, 25 May 2022 01:41:06 +0300 (MSK) Received: from vla3-3dd1bd6927b2.qloud-c.yandex.net (vla3-3dd1bd6927b2.qloud-c.yandex.net [2a02:6b8:c15:350f:0:640:3dd1:bd69]) by vla1-7741ebbbf6f0.qloud-c.yandex.net (mxback/Yandex) with ESMTP id XBegJJ1ykZ-f5deMZYo; Wed, 25 May 2022 01:41:06 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1653432066; bh=svRvA6sZ2mggRKyOzy1/+lo/CZ/exO8+91RPJ2zjwxo=; h=In-Reply-To:From:Subject:Cc:References:Date:Message-ID:To; b=FFZL22lXO5zqIXi60V0Ht5QQA0aUL04MfrF8Tf1PDh3N3d4hkXMaCJeeOsA0gOX5z Rt6bHK2ogrWnl/RlwF4f9Rema1hYBkl4KOvJU0eNrooMdcynp6Gjc5jw6o0VbkK1YU u3WaYrbUIjOAmmgZf03Sh/zSIevwHKH+vRDf4Utk= Authentication-Results: vla1-7741ebbbf6f0.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla3-3dd1bd6927b2.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id UhJwsUb7tk-f4JOvPa0; Wed, 25 May 2022 01:41:04 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <703d366e-43d8-f46c-5e8b-ee91f2848daa@yandex.ru> Date: Tue, 24 May 2022 23:41:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH 2/4] net/bonding: move testpmd commands Content-Language: en-US To: Thomas Monjalon , Andrew Rybchenko , David Marchand Cc: dev@dpdk.org, "Min Hu (Connor)" , Xiaoyun Li , Aman Singh , Yuying Zhang , Chas Williams , jerinj@marvell.com References: <20220513075718.18674-1-david.marchand@redhat.com> <8524011.OUTRe80PYV@thomas> From: Konstantin Ananyev In-Reply-To: <8524011.OUTRe80PYV@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:15, Thomas Monjalon пишет: > 24/05/2022 11:40, Konstantin Ananyev: >> 20/05/2022 07:59, Andrew Rybchenko пишет: >>> 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 пишет: >>>>>>> On Fri, May 13, 2022 at 12:10 PM Min Hu (Connor) >>>>>>> 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. >>> >>> +1 >>> >>>> >>>>>> 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)... >>>>> >>>>> 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. >>> >>> +1 >>> >>>> >>>>> 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. >>> >>> +1 >>> >>>> >>>>> 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 driver >>>> or lib directory: >>>> https://mails.dpdk.org/archives/dev/2022-April/239191.html >> >> 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 Ok, if we already doing it that way for some dev types, then probably no point to do it differently for netdev.