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

[Jiri Pirko <jiri@resnulli.us>]

Sat, Jun 24, 2023 at 10:47:03PM CEST, kuba@kernel.org wrote:
>On Sat, 24 Jun 2023 11:33:20 +0200 Jiri Pirko wrote:
>> >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.
>
>"Let's piggyback on something else in the uAPI because I don't want 
>to extend FW" is not an argument which can be taken seriously.

It's not about what I want or not. It's about what can realistically
happen (not talking about mlx5 specifically).

But what is a difference between using hw_addr and some other uuid.
cmdline wise:

option 1 - JUST HW_ADDR:

$ sudo devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 103
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 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/32770 hw_addr AA:22:33:44:55:66

$ sudo devlink port show pci/0000:08:00.0/32770
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 state inactive opstate detached

$ sudo devlink port function set pci/0000:08:00.0/32770 state active
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 state active opstate detached devlink_handle auxiliary/mlx5_core.eth.5
# This is new, currently activation does not give feedback,
# devlink_handle attr is new here

$ sudo devlink port show pci/0000:08:00.0/32770
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 state active opstate attached devlink_handle auxiliary/mlx5_core.eth.5
# devlink_handle attr is new here

$ sudo devlink dev show auxiliary/mlx5_core.eth.5
auxiliary/mlx5_core.eth.5: hw_addr aa:22:33:44:55:66
# hw_addr attr is new here

hw_addr value is passed through FW here. This value is currently used
for netdevice mac. So it is just a matter of exposing for auxdev
devlink/devlink_port (not 100% sure which)


option 2 - ADDED UUID:

$ sudo devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 103
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 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/32770 hw_addr AA:22:33:44:55:66 uuid SOMETHINGREALLYUNIQUE

$ sudo devlink port show pci/0000:08:00.0/32770
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 uuid SOMETHINGREALLYUNIQUE state inactive opstate detached
# uuid attr is new here

$ sudo devlink port function set pci/0000:08:00.0/32770 state active
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 uuid SOMETHINGREALLYUNIQUE state active opstate detached devlink_handle auxiliary/mlx5_core.eth.5
# This is new, currently activation does not give feedback,
# devlink_handle attr is new here, uuid attr is new here

$ sudo devlink port show pci/0000:08:00.0/32770
pci/0000:08:00.0/32770: type eth netdev eth10 flavour pcisf controller 0 pfnum 0 sfnum 103 splittable false
  function:
    hw_addr aa:22:33:44:55:66 uuid SOMETHINGREALLYUNIQUE state active opstate attached devlink_handle auxiliary/mlx5_core.eth.5
# devlink_handle attr is new here, uuid attr is new here

$ sudo devlink dev show auxiliary/mlx5_core.eth.5
auxiliary/mlx5_core.eth.5: uuid SOMETHINGREALLYUNIQUE
# uuid attr is new here

uuid value is passed through FW here.


The uuid kind of values is nothing new in netdev. We have:
IFLA_PHYS_PORT_ID
IFLA_PHYS_SWITCH_ID
In most of the cases (if not all), these are in drivers filled-up with
MAC. So I'm quite positive that the drivers would implement the auxdev
uuid as a MAC as well.

Do you like option 2 better than option 1? Is there option 3?

Thanks!