-----Original Message-----
From: Ajit Khaparde <ajit.khaparde@broadcom.com>
Sent: Tuesday, January 19, 2021 2:18 AM
To: NBU-Contact-Thomas Monjalon <redacted>
Cc: Xueming(Steven) Li <redacted>; Ferruh Yigit
[off-list ref]; Andrew Rybchenko
[off-list ref]; Olivier Matz [off-list ref];
dpdk-dev [off-list ref]; Slava Ovsiienko [off-list ref]; Asaf
Penso [off-list ref]
Subject: Re: [dpdk-dev] [PATCH v4 1/9] ethdev: introduce representor type

On Mon, Jan 18, 2021 at 10:15 AM Thomas Monjalon [off-list ref]
wrote:

quoted

18/01/2021 19:00, Ajit Khaparde:

quoted

On Mon, Jan 18, 2021 at 9:57 AM Thomas Monjalon

[off-list ref] wrote:

quoted

quoted

quoted

18/01/2021 18:42, Ajit Khaparde:

quoted

On Mon, Jan 18, 2021 at 3:17 AM Xueming Li [off-list ref]

wrote:

quoted

quoted

quoted

quoted

quoted

+enum rte_eth_representor_type {
+       RTE_ETH_REPRESENTOR_NONE, /**< not a representor. */
+       RTE_ETH_REPRESENTOR_VF,   /**< representor of VF. */
+       RTE_ETH_REPRESENTOR_SF,   /**< representor of SF. */

Till we get used to the terminology...
Can we also have SF = "Sub Function" mentioned in the docs or

comments?

quoted

quoted

quoted

Are we sure about the definition?
I remember seeing SF = Scalable Function somewhere else (maybe from

Intel)

quoted

quoted

That complicates it. But if they mean the same thing, let's pick one.

I think "Sub Function" and "Virtual Function" are easy to understand
for everybody.
I suggest picking these two for comments above.

+1

There was an internal discussion and the conclusion is to align with kernel driver name.
Will update comment in next version, thanks!

quoted