[EXT] Re: [PATCH v3 0/4] implementation of ML common code

[Jerin Jacob]

On Fri, Jan 27, 2023 at 2:20 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> 27/01/2023 07:40, Jerin Jacob:
> > On Thu, Jan 26, 2023 at 4:27 PM Thomas Monjalon <thomas at monjalon.net> wrote:
> > > 25/01/2023 15:59, Srikanth Yalavarthi:
> > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > 25/01/2023 14:25, Srikanth Yalavarthi:
> > > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > > 20/12/2022 18:52, Srikanth Yalavarthi:
> > > > > > > > This patch series implements the common ML code that can be used
> > > > > > > > by ML drivers. Common code include functions to convert ML IO type
> > > > > > > > to string, IO format type to string, function get size of ML IO
> > > > > > > > type, and functions for converting data types from higher
> > > > > > > > precision to lower precision and vice-versa.
> > > > > > >
> > > > > > > I'm not sure about the path of this code.
> > > > > > > In general we implement drivers helper in the same directory as the
> > > > > > > driver and mark it as internal.
> > > > > > > Would it work here?
> > > > > >
> > > > > > We are planning to implement two different ML drivers, ml/cnxk driver
> > > > > (submitted for review) and a software only driver (part of ML roadmap and
> > > > > currently WIP). Both the drivers would be using these common functions for
> > > > > quantization and dequantization. Hence, placed the files in common/ml
> > > > > directory.
> > > > > >
> > > > > > Moreover, these functions are used to convert data from higher to lower
> > > > > precision or vice-versa and  can also be used by future ML drivers for other
> > > > > platforms.
> > > > >
> > > > > I understand, and what you say does not contradict with having this code in
> > > > > lib/mldev/.
> > > > > So would you agree to move?
> > > >
> > > > These common functions do not have an rte_ml_dev_ prefix.
> > >
> > > As it is exported, it should have rte_ prefix.
> >
> > The exposed functions are similar to lib/ethdev/sff_* where multiple
> > driver can "use" it
> > but not by application directly.
> > If so, What is the recommendation
> > a) Keeping driver/common/ml without rte_prefix
> > b) Keeping in lib/mldev/ with rte_mldev_pmd_ prefix?
> >
> > I prefer (a) as it will not pollute lib/mldev. No strong opinion,
> > either. Let me know your view or any other suggestion?
>
> I don't see it as pollution, it comes with the library,
> so I prefer lib/mldev/ with rte_mldev_pmd_ prefix.
>
>
> > > Is it ok to have non-RTE code in lib/mldev. If yes, we can move to lib/mldev.
> > >
> > > Look at lib/ethdev/ethdev_driver.h, it should be similar.
> >
> > Here scope is different. See above.
>
> No the scope is not different.
> They are functions used by drivers not by application.

When you say lib/ethdev/ethdev_driver.h. You mean "struct eth_dev_ops" scheme.
That is already there for public ml dev APIs. See
http://patches.dpdk.org/project/dpdk/patch/20221114120238.2143832-4-jerinj@marvell.com/

Here it meant to be functions which is not backed any function
pointers as those are "generic"
Utils for drivers(not driver specific). If so, did you prefer
rte_mldev_pmd_ in lib/mldev/ ?



>
>
>