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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 10 Jun 2023 21:15:57 -0700
From: Saeed Mahameed <saeedm@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Saeed Mahameed <saeed@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>,
	Shay Drory <shayd@...dia.com>, Moshe Shemesh <moshe@...dia.com>
Subject: Re: [net-next 14/15] net/mlx5: Light probe local SFs

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.