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 CC1FCA04FF; Tue, 24 May 2022 11:40:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC7B640A87; Tue, 24 May 2022 11:40:13 +0200 (CEST) Received: from forward501j.mail.yandex.net (forward501j.mail.yandex.net [5.45.198.251]) by mails.dpdk.org (Postfix) with ESMTP id 1E4F440A84 for ; Tue, 24 May 2022 11:40:13 +0200 (CEST) Received: from iva1-5d4bed9ec33e.qloud-c.yandex.net (iva1-5d4bed9ec33e.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:298:0:640:5d4b:ed9e]) by forward501j.mail.yandex.net (Yandex) with ESMTP id AF3D0623590; Tue, 24 May 2022 12:40:12 +0300 (MSK) Received: from iva3-dd2bb2ff2b5f.qloud-c.yandex.net (iva3-dd2bb2ff2b5f.qloud-c.yandex.net [2a02:6b8:c0c:7611:0:640:dd2b:b2ff]) by iva1-5d4bed9ec33e.qloud-c.yandex.net (mxback/Yandex) with ESMTP id NoYRx10IPO-eBf4RSq4; Tue, 24 May 2022 12:40:12 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1653385212; bh=wY7gZcGw9DUjCyOgPuNWLHJwihpZY3oM/sRP4ANe+fQ=; h=In-Reply-To:From:Subject:Cc:References:Date:Message-ID:To; b=CceryU6qWLXSXcQobt0NlyGgM4etlxyOl7k0QN32Vy55EzT7CrXVcXFcpNy/mvpS6 AoQ229Hq4cNKN2W79aISzTaLUq8n1InLE/h5cOCHwZnT5nDCyYC41x5mTo4CjEGcc7 rzu090IBww1uofFm4ykiVRLM5O9Ws8NQdvBoCS48= Authentication-Results: iva1-5d4bed9ec33e.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva3-dd2bb2ff2b5f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id TpGgb4FuFd-e9H8GN4P; Tue, 24 May 2022 12:40:10 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: Date: Tue, 24 May 2022 10:40:08 +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: Andrew Rybchenko , Thomas Monjalon , 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> <581f038e-a50a-175e-8336-c82f617954f5@yandex.ru> <2187851.KTMopqUuYO@thomas> From: Konstantin Ananyev In-Reply-To: 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 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? >> >>> If we keep those in app/test-pmd, it is still possible to mark the >>> driver-specific sources in MAINTAINERS, but such updates are often >>> missed. >>> I can probably add something in devtools/ to catch those updates in >>> the future... >>> >>> I'll try for RFC v3. >> >> >> >