Re: [net-next 14/15] net/mlx5: Light probe local SFs

[Jiri Pirko <jiri@resnulli.us>]

Fri, Jun 23, 2023 at 05:21:08PM CEST, kuba@kernel.org wrote:
>On Fri, 23 Jun 2023 11:27:10 +0200 Jiri Pirko wrote:
>> Thu, Jun 22, 2023 at 06:35:23PM CEST, kuba@kernel.org wrote:
>> >SG. For the IPU case when spawning from within the IPU can we still
>> >figure out what the auxdev id is going to be? If not maybe we should  
>> 
>> Yeah, the driver is assigning the auxdev id. I'm now trying to figure
>> out how to pass that to devlink code/user nicely. The devlink instance
>> for the SF does not exist yet, but we know what the handle is going to
>> be. Perhaps some sort of place holder instance would do. IDK.
>> 
>> >add some form of UUID on both the port and the sf devlink instance?  
>> 
>> What about the MAC?
>> 
>> $ sudo devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 102
>> pci/0000:08:00.0/32769: type eth netdev eth8 flavour pcisf controller 0 pfnum 0 sfnum 102 splittable false
>>   function:
>>     hw_addr 00:00:00:00:00:00 state inactive opstate detached
>> $ sudo devlink port function set pci/0000:08:00.0/32769 hw_addr AA:22:33:44:55:66
>> $ sudo devlink port function set pci/0000:08:00.0/32769 state active
>> $ ip link show eth9
>> 15: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>     link/ether aa:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff
>> 
>> There are 2 issues with this:
>> 1) If the hw_addr stays zeroed for activation, random MAC is generated
>> 2) On the SF side, the MAC is only seen for netdev. That is problematic
>>    for SFs without netdev. However, I don't see why we cannot add
>>    devlink port attr to expose hw_addr on the SF.
>
>Yeah, the fact that mac add of zero has special meaning could be

True. But I believe we can sanitize this in devlink core, not allowing
to activate zeroed mac. Instead of radom generating of a mac on the SF
side, we random generate it on the eswitch port function side.

I think this can work.


>problematic. Other vendors may get "inspired" by the legacy SR-IOV
>semantics of MAC addr of zero == user can decide, or whatnot.
>The value on the port is the admin-set MAC, not the current MAC

True, that is why I suggested to expose hw_addr attr on devlink port of
the SF instance, where this would be fixed no matter what the user does
on the actual netdevice.


>of the SF after all, right? Probably best to find another way...


Well, yeah. The mac/hw_addr is quite convenient. It's there and
I believe that any device could work with that. Having some kind of
"extra cookie" would require to implement that in FW, which makes things
more complicated.


>
>> >Maybe there's already some UUID in the vfio world we can co-opt?  
>> 
>> Let me check that out.