Re: [dpdk-dev] [PATCH] ethdev: support action with any config object type

[Dekel Peled <dekelp@mellanox.com>]

Thanks, PSB.

> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Tuesday, July 2, 2019 1:12 PM
> To: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Dekel Peled
> <dekelp@mellanox.com>
> Cc: wenzhuo.lu@intel.com; jingjing.wu@intel.com;
> bernard.iremonger@intel.com; Yongseok Koh <yskoh@mellanox.com>;
> Shahaf Shuler <shahafs@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; dev@dpdk.org; Ori Kam
> <orika@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH] ethdev: support action with any config
> object type
> 
> On 02.07.2019 12:57, Adrien Mazarguil wrote:
> > On Tue, Jul 02, 2019 at 08:42:41AM +0000, Dekel Peled wrote:
> >> Thanks, PSB.
> >>
> >>> -----Original Message-----
> >>> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >>> Sent: Tuesday, July 2, 2019 11:09 AM
> >>> To: Dekel Peled <dekelp@mellanox.com>; Adrien Mazarguil
> >>> <adrien.mazarguil@6wind.com>; wenzhuo.lu@intel.com;
> >>> jingjing.wu@intel.com; bernard.iremonger@intel.com; Yongseok Koh
> >>> <yskoh@mellanox.com>; Shahaf Shuler <shahafs@mellanox.com>;
> Slava
> >>> Ovsiienko <viacheslavo@mellanox.com>; arybchenko@solarflare.com
> >>> Cc: dev@dpdk.org; Ori Kam <orika@mellanox.com>
> >>> Subject: Re: [dpdk-dev] [PATCH] ethdev: support action with any
> >>> config object type
> >>>
> >>> On 01.07.2019 17:10, Dekel Peled wrote:
> >>>> In current implementation, an action which requires parameters must
> >>>> accept them enclosed in a structure.
> >>>> Some actions require a single, trivial type parameter, but it still
> >>>> must be enclosed in a structure.
> >>>> This obligation results in multiple, action-specific structures,
> >>>> each containing a single trivial type parameter.
> >>>>
> >>>> This patch introduces a new approach, allowing an action
> >>>> configuration object of any type, trivial or a structure.
> >>>>
> >>>> This patch introduces, in test-pmd, a new macro ARG_ENTRY_HTON, to
> >>>> allow using a single argument, not enclosed in a structure.
> >>>>
> >>>> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> >>> The term "object" confuses me a bit, but I'm not a native speaker so
> >>> it could be just my wrong association. I'd prefer "configuration data".
> >> In previous version I wrote just "action configuration", and changed to
> "action configuration object" per Adrien's suggestion. I think it is better, but if
> it causes confusion maybe it should be changed.
> >>
> >> Adrien, what do you think? Does "configuration data" carry the correct
> meaning?
> > Well I'm no native speaker either but "object" is the term used in the
> > C standard with a well-defined meaning [1] and encompasses everything
> > (integers, floats, structures, unions, functions, pointers, arrays):
> >
> >   "region of data storage in the execution environment, the contents of
> which
> >    can represent values"
> >
> > I think it's a bit less vague than "data" because whenever objects are
> > mentioned in the standard, they always have a type. There's no such
> > thing as a C object without one, and rte_flow puts a lot of emphasis
> > on documenting them.
> >
> >   int foo;
> >   struct { ... } foo;
> >   double foo;
> >   char foo[];
> >   void *foo;
> >
> > Whatever the type, would you refer to "foo" itself as an "object" or
> > as "data"?
> 
> Adrien, thanks a lot. Now "object" looks OK and better than "data".

Agreed, staying with "object".

> 
> > Unrelated, but you must remove ARG_ENTRY_HTON from this patch since
> > there's no testpmd change in there that requires it. There's no
> > tolerance for dead code in testpmd as it doesn't expose an API.
> >
> > Thanks.
> >
> > [1] 3.14 "object"
> >
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> open-
> std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1256.pdf&amp;data
> =02%7C01%7Cdekelp%40mellanox.com%7C65a76c486a4441d6a05e08d6fed5
> ba8d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C6369765912801
> 35692&amp;sdata=INAfwwiVUvf6c19OcTiW1K27qeIHhrk7Nk2uVu3EDjA%3D
> &amp;reserved=0
> >