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

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

>>
>>> 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.
>>
>>
>>
>