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

From: Saeed Mahameed <[email-masked]>
Date: Sat, 10 Jun 2023 21:15:57 -0700

On 10 Jun 00:01, Jakub Kicinski wrote:
>On Fri,  9 Jun 2023 18:42:53 -0700 Saeed Mahameed wrote:
>> In case user wants to configure the SFs, for example: to use only vdpa
>> functionality, he needs to fully probe a SF, configure what he wants,
>> and afterward reload the SF.
>>
>> In order to save the time of the reload, local SFs will probe without
>> any auxiliary sub-device, so that the SFs can be configured prior to
>> its full probe.
>
>I feel like we talked about this at least twice already, and I keep
>saying that the features should be specified when the device is
>spawned. Am I misremembering?
>

I think we did talk about this, but after internal research we prefer to
avoid adding additional knobs, unless you insist :) .. 
I think we already did a research and we feel that all of our users are
going to re-configure the SF anyway, so why not make all SFs start with
"blank state" ?

>Will this patch not surprise existing users? You're changing the

I think we already checked, the feature is still not widely known.
Let me double check.

>defaults. Does "local" mean on the IPU? Also "lightweight" feels
>uncomfortably close to marketing language.
>

That wasn't out intention, poor choice of words, will reword to "blank SF"

>> The defaults of the enable_* devlink params of these SFs are set to
>> false.
>>
>> Usage example:
>
>Is this a real example? Because we have..
>
>> Create SF:
>> $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11
>
>sfnum 11 here
>

This an arbitrary user index.

>> $ devlink port function set pci/0000:08:00.0/32768 \
>
>then port is 32768
>

This is the actual HW port index, our SFs indexing start with an offset.

>>                hw_addr 00:00:00:00:00:11 state active
>>
>> Enable ETH auxiliary device:
>> $ devlink dev param set auxiliary/mlx5_core.sf.1 \
>
>and instance is sf.1
>

This was the first SF aux dev to be created on the system. :/

It's a mess ha...
  
Maybe we need to set the SF aux device index the same as the user index.
But the HW/port index will always be different, otherwise we will need a map
inside the driver.