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