From: Srikanth Yalavarthi <syalavarthi@marvell.com>
To: Jerin Jacob <jerinjacobk@gmail.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: Shivah Shankar Shankar Narayan Rao <sshankarnara@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Anup Prabhu <aprabhu@marvell.com>,
"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
Srikanth Yalavarthi <syalavarthi@marvell.com>
Subject: RE: [EXT] Re: [PATCH v3 0/4] implementation of ML common code
Date: Tue, 31 Jan 2023 13:44:35 +0000 [thread overview]
Message-ID: <CO6PR18MB39399EE16468846F9FAAEE1EAED09@CO6PR18MB3939.namprd18.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1NAKymsVZd12k0Nt0qaS7dU1vOq17dP743=SC=egqWDmQ@mail.gmail.com>
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: 27 January 2023 15:58
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Shivah Shankar Shankar Narayan Rao <sshankarnara@marvell.com>;
> Srikanth Yalavarthi <syalavarthi@marvell.com>; dev@dpdk.org; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Anup Prabhu
> <aprabhu@marvell.com>; ferruh.yigit@amd.com;
> bruce.richardson@intel.com; david.marchand@redhat.com; Srikanth
> Yalavarthi <syalavarthi@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 <thomas@monjalon.net>
> wrote:
> >
> > 27/01/2023 10:02, Jerin Jacob:
> > > On Fri, Jan 27, 2023 at 2:20 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > > 27/01/2023 07:40, Jerin Jacob:
> > > > > On Thu, Jan 26, 2023 at 4:27 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > > > > 25/01/2023 15:59, Srikanth Yalavarthi:
> > > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > 25/01/2023 14:25, Srikanth Yalavarthi:
> > > > > > > > > From: Thomas Monjalon <thomas@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.
>
> >
> >
> >
next prev parent reply other threads:[~2023-01-31 13:44 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 19:35 [PATCH v1 " Srikanth Yalavarthi
2022-12-08 19:35 ` [PATCH v1 1/4] common/ml: add initial files for " Srikanth Yalavarthi
2022-12-08 19:35 ` [PATCH v1 2/4] common/ml: add data type conversion routines Srikanth Yalavarthi
2022-12-08 19:35 ` [PATCH v1 3/4] common/ml: add generic type conversion functions Srikanth Yalavarthi
2022-12-08 19:35 ` [PATCH v1 4/4] common/ml: add Arm NEON type conversion routines Srikanth Yalavarthi
2022-12-12 7:16 ` Ruifeng Wang
2022-12-12 17:25 ` Srikanth Yalavarthi
2022-12-12 17:21 ` [PATCH v1 0/4] implementation of ML common code Srikanth Yalavarthi
2022-12-12 17:21 ` [PATCH v2 1/4] common/ml: add initial files for " Srikanth Yalavarthi
2022-12-12 17:21 ` [PATCH v2 2/4] common/ml: add common utility functions Srikanth Yalavarthi
2022-12-12 17:21 ` [PATCH v2 3/4] common/ml: add scalar type conversion functions Srikanth Yalavarthi
2022-12-12 17:21 ` [PATCH v2 4/4] common/ml: add Arm NEON type conversion routines Srikanth Yalavarthi
2022-12-13 9:04 ` Ruifeng Wang
2022-12-20 17:52 ` [PATCH v3 0/4] implementation of ML common code Srikanth Yalavarthi
2022-12-20 17:52 ` [PATCH v3 1/4] common/ml: add initial files for " Srikanth Yalavarthi
2022-12-20 19:04 ` Stephen Hemminger
2022-12-20 19:19 ` [EXT] " Srikanth Yalavarthi
2022-12-20 17:52 ` [PATCH v3 2/4] common/ml: add common utility functions Srikanth Yalavarthi
2022-12-20 17:52 ` [PATCH v3 3/4] common/ml: add scalar type conversion functions Srikanth Yalavarthi
2022-12-20 17:52 ` [PATCH v3 4/4] common/ml: add Arm NEON type conversion routines Srikanth Yalavarthi
2022-12-21 3:08 ` Ruifeng Wang
2022-12-20 19:06 ` [PATCH v3 0/4] implementation of ML common code Stephen Hemminger
2022-12-20 19:17 ` [EXT] " Srikanth Yalavarthi
2023-01-25 13:18 ` Thomas Monjalon
2023-01-25 13:25 ` [EXT] " Srikanth Yalavarthi
2023-01-25 13:55 ` Thomas Monjalon
2023-01-25 14:59 ` Srikanth Yalavarthi
2023-01-26 10:57 ` Thomas Monjalon
2023-01-27 6:40 ` Jerin Jacob
2023-01-27 8:50 ` Thomas Monjalon
2023-01-27 9:02 ` Jerin Jacob
2023-01-27 9:26 ` Thomas Monjalon
2023-01-27 10:28 ` Jerin Jacob
2023-01-31 13:44 ` Srikanth Yalavarthi [this message]
2023-02-01 9:15 ` Srikanth Yalavarthi
2023-02-01 9:04 ` [PATCH v4 0/4] Implementation " Srikanth Yalavarthi
2023-02-01 9:04 ` [PATCH v4 1/4] mldev: add headers for internal ML functions Srikanth Yalavarthi
2023-02-01 13:54 ` Anup Prabhu
2023-02-01 15:28 ` Thomas Monjalon
2023-02-01 9:04 ` [PATCH v4 2/4] mldev: implement ML IO type handling functions Srikanth Yalavarthi
2023-02-01 13:53 ` Anup Prabhu
2023-02-01 14:01 ` Anup Prabhu
2023-02-01 14:15 ` Anup Prabhu
2023-02-01 14:26 ` Anup Prabhu
2023-02-01 9:04 ` [PATCH v4 3/4] mldev: add scalar type conversion functions Srikanth Yalavarthi
2023-02-01 9:04 ` [PATCH v4 4/4] mldev: add Arm NEON type conversion routines Srikanth Yalavarthi
2023-02-01 9:12 ` [PATCH v5 0/4] Implementation of ML common code Srikanth Yalavarthi
2023-02-01 9:12 ` [PATCH v5 1/4] mldev: add headers for internal ML functions Srikanth Yalavarthi
2023-02-01 9:12 ` [PATCH v5 2/4] mldev: implement ML IO type handling functions Srikanth Yalavarthi
2023-02-02 4:20 ` Anup Prabhu
2023-02-01 9:12 ` [PATCH v5 3/4] mldev: add scalar type conversion functions Srikanth Yalavarthi
2023-02-01 9:12 ` [PATCH v5 4/4] mldev: add Arm NEON type conversion routines Srikanth Yalavarthi
2023-02-07 16:00 ` [PATCH v6 0/4] Implementation of ML common code Srikanth Yalavarthi
2023-02-07 16:00 ` [PATCH v6 1/4] mldev: add headers for internal ML functions Srikanth Yalavarthi
2023-03-09 20:44 ` Thomas Monjalon
2023-02-07 16:00 ` [PATCH v6 2/4] mldev: implement ML IO type handling functions Srikanth Yalavarthi
2023-02-07 16:00 ` [PATCH v6 3/4] mldev: add scalar type conversion functions Srikanth Yalavarthi
2023-02-07 16:00 ` [PATCH v6 4/4] mldev: add Arm NEON type conversion routines Srikanth Yalavarthi
2023-03-09 21:37 ` [PATCH v6 0/4] Implementation of ML common code Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CO6PR18MB39399EE16468846F9FAAEE1EAED09@CO6PR18MB3939.namprd18.prod.outlook.com \
--to=syalavarthi@marvell.com \
--cc=aprabhu@marvell.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=sshankarnara@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).