Re: [RFC PATCH 2/4] net/bonding: move testpmd commands

From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
To: Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, "Min Hu (Connor)" <humin29@huawei.com>,
	Xiaoyun Li <xiaoyun.li@intel.com>,
	Aman Singh <aman.deep.singh@intel.com>,
	Yuying Zhang <yuying.zhang@intel.com>,
	Chas Williams <chas3@att.com>,
	jerinj@marvell.com
Subject: Re: [RFC PATCH 2/4] net/bonding: move testpmd commands
Date: Tue, 24 May 2022 23:41:02 +0100	[thread overview]
Message-ID: <703d366e-43d8-f46c-5e8b-ee91f2848daa@yandex.ru> (raw)
In-Reply-To: <8524011.OUTRe80PYV@thomas>

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
>>>>> <konstantin.v.ananyev@yandex.ru> wrote:
>>>>>> 18/05/2022 18:24, David Marchand пишет:
>>>>>>> On Fri, May 13, 2022 at 12:10 PM Min Hu (Connor)
>>>>>>> <humin29@huawei.com> 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.