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