RE: [PATCH RESEND iproute2-next] devlink: Add optional controller user input

[Parav Pandit <parav@nvidia.com>]

> From: Yunsheng Lin <linyunsheng@huawei.com>
> Sent: Wednesday, June 9, 2021 5:05 PM
> 
> On 2021/6/9 17:24, Parav Pandit wrote:
> >> From: Yunsheng Lin <linyunsheng@huawei.com>
> >>
> >> I thought the representor ports of a PF'eswitch is decided by the
> >> function under a specific PF(For example, the PF itself and the VF under
> this PF)?
> >
> > Eswitch is not per PF in context of smartnic/multi-host.
> 
> So the Eswitch may be per PF in context of *non*-"smartnic/multi-host",
> right?
Right.

> It seems that it makes more sense to set the eswitch mode based on devlink
> port instance instead of devlink instance if devlink instance represents a
> multi-function ASIC?
Devlink ports are the children/sub objects of devlink instance.
Eswitch mode is per devlink instance that drives how its sub objects to be handled.
Shouldn't be other way around.

If you mean to say, that in multi-function ASIC, ASIC capabilities decide which devlink instance to support eswitch (and hence its ports), it make sense to me.

> 
> > PF _has_ eswitch that contains the representor ports for PF, VF, SF.
> >
> >>
> >>> Each representor port represent either PF, VF or SF.
> >>> This PF, VF or SF can be of local controller residing on the eswitch
> >>> device or
> >> it can be of an external controller(s).
> >>> Here external controller = 1.
> >>
> >> If I understood above correctly:
> >> The fw/hw decide which PF has the eswitch, and how many
> >> devlink/representor port does this eswitch has?
> > Number of ports are dynamic. When new SFs/VFs are created, ports get
> added to the switch.
> >
> >> Suppose PF0 of controller_num=0 in have the eswitch, and the eswitch
> >> may has devlink/representor port representing other PF, like PF1 in
> >> controller_num=0, and even PF0/PF1 in controller_num=1?
> > Yes. Correct.
> 
> Thanks for clarifying, I think I can see the big picture now.
> 
> >