[dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor

Ajit Khaparde ajit.khaparde at broadcom.com
Wed Jan 27 18:43:21 CET 2021


On Tue, Jan 26, 2021 at 7:05 PM Xueming(Steven) Li <xuemingl at nvidia.com> wrote:
>
::::[snip]::::
> The patch of device SF capability, but seems I misunderstood your suggestion.
> 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.
> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
> If using new api to return all representor IDs, need some way locate the new created SF by PF and SF number,
> 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
> to support more device expressions and types. But that will introduce a fundamental change of devargs and
> 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?
More types of what?

>
> >
> >Andrew.
>


More information about the dev mailing list