Hi Ajit,

-----Original Message-----
From: Ajit Khaparde <ajit.khaparde@broadcom.com>
Sent: Thursday, January 28, 2021 1:43 AM
To: Xueming(Steven) Li <redacted>
Cc: Andrew Rybchenko <redacted>; dev@dpdk.org;
Slava Ovsiienko [off-list ref]; Asaf Penso [off-list ref]
Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction
representor

On Tue, Jan 26, 2021 at 7:05 PM Xueming(Steven) Li [off-list ref]
wrote:

quoted

::::[snip]::::

quoted

The patch of device SF capability, but seems I misunderstood your

suggestion.

quoted

Let me explain process to create a SF:
1. SF can be created on the fly with scripts, unlike VF which is statically pre-

created.

quoted

2. SF is created on a PF with a SF number. SF number is named per PF,

different PF may have same SF number.

quoted

3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no

need to use pf#sf# here.

quoted

4. For bonding netdev, hot plug to DPDK using

"PF0_BDF,representor=pf#sf#"

quoted

If using new api to return all representor IDs, need some way locate the new

created SF by PF and SF number,

quoted

that's why "pf#sf#" is used in this patch set.

In the future, I think representor could be processed by PMD, so PMD could

have enough flexibility

quoted

to support more device expressions and types. But that will introduce a

fundamental change of devargs and

quoted

device management, need a full plan.

Do you mean all changes will be contained within the PMD? The
fundamental changes will be in the PMD?

Yes, PMD detect device type and IDs from devargs and figure out a unique name for device.

More types of what?

SF, representor of SF, representor of VF...

quoted

quoted

Andrew.