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