Srikanth Yalavarthi Senior Staff Engineer
> -----Original Message----- > From: Srikanth Yalavarthi <syalavar...@marvell.com> > Sent: 31 January 2023 19:15 > To: Jerin Jacob <jerinjac...@gmail.com>; Thomas Monjalon > <tho...@monjalon.net> > Cc: Shivah Shankar Shankar Narayan Rao <sshankarn...@marvell.com>; > dev@dpdk.org; Jerin Jacob Kollanukkaran <jer...@marvell.com>; Anup > Prabhu <apra...@marvell.com>; ferruh.yi...@amd.com; > bruce.richard...@intel.com; david.march...@redhat.com; Srikanth > Yalavarthi <syalavar...@marvell.com>; Srikanth Yalavarthi > <syalavar...@marvell.com> > Subject: RE: [EXT] Re: [PATCH v3 0/4] implementation of ML common code > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: 27 January 2023 15:58 > > To: Thomas Monjalon <tho...@monjalon.net> > > Cc: Shivah Shankar Shankar Narayan Rao <sshankarn...@marvell.com>; > > Srikanth Yalavarthi <syalavar...@marvell.com>; dev@dpdk.org; Jerin > > Jacob Kollanukkaran <jer...@marvell.com>; Anup Prabhu > > <apra...@marvell.com>; ferruh.yi...@amd.com; > > bruce.richard...@intel.com; david.march...@redhat.com; Srikanth > > Yalavarthi <syalavar...@marvell.com> > > Subject: Re: [EXT] Re: [PATCH v3 0/4] implementation of ML common code > > > > On Fri, Jan 27, 2023 at 2:56 PM Thomas Monjalon <tho...@monjalon.net> > > wrote: > > > > > > 27/01/2023 10:02, Jerin Jacob: > > > > On Fri, Jan 27, 2023 at 2:20 PM Thomas Monjalon > > <tho...@monjalon.net> wrote: > > > > > 27/01/2023 07:40, Jerin Jacob: > > > > > > On Thu, Jan 26, 2023 at 4:27 PM Thomas Monjalon > > <tho...@monjalon.net> wrote: > > > > > > > 25/01/2023 15:59, Srikanth Yalavarthi: > > > > > > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > > > > > > 25/01/2023 14:25, Srikanth Yalavarthi: > > > > > > > > > > From: Thomas Monjalon <tho...@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. > > > > > > No I don't mean that. Did you check the internal functions in this file? > > > I mean functions like rte_eth_dev_allocate() or > > rte_eth_dev_attach_secondary(). > > > > Got it. Let's change to rte_ml_pmd_ prefix and add to lib/mldev then. > > Considering the scope of these functions, I think, instead of rte_ml_pmd_ > prefix, rte_ml_io_ prefix is more suitable? Also it would in similar lines > with > internal functions defined in other libraries. > > I can push the push a revised patch series accordingly. Updated the series. Moved the code to lib/mldev and added rte_ml_io_ prefix to the functions. http://patches.dpdk.org/project/dpdk/list/?series=26731 > > > > > > > > > > >
