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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Sat, 10 Jun 2023 22:10:19 -0700
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Saeed Mahameed <saeedm@...dia.com>, 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 6/10/2023 9:15 PM, Saeed Mahameed wrote:
> 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" ?

Shouldn't this be a devlink port param to enable/disable a specific 
feature on the SF before it is activated rather than making it a dev 
param on the SF aux device and requiring a devlink reload?

> 
>> 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.

Yes. Associating sfnum passed by user when creating a SF with the aux 
device would make it easier for orchestration tools to identify the aux 
device corresponding to a SF.