netdev - Re: [PATCH net-next v2 00/15][pull request] ice: support devlink subfunction

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] [day] [month] [year] [list]

Message-ID: <1717b59f-2fc6-3eb6-9659-c950e3f9d3b2@intel.com>
Date: Tue, 6 Aug 2024 14:13:27 -0700
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <netdev@...r.kernel.org>, <jiri@...dia.com>,
	<shayd@...dia.com>, <wojciech.drewek@...el.com>, <horms@...nel.org>,
	<sridhar.samudrala@...el.com>, <mateusz.polchlopek@...el.com>,
	<kalesh-anakkur.purayil@...adcom.com>, <michal.kubiak@...el.com>,
	<pio.raczynski@...il.com>, <przemyslaw.kitszel@...el.com>,
	<jacob.e.keller@...el.com>, <maciej.fijalkowski@...el.com>
Subject: Re: [PATCH net-next v2 00/15][pull request] ice: support devlink
 subfunction



On 8/2/2024 11:51 PM, Jiri Pirko wrote:
> Fri, Aug 02, 2024 at 07:38:34PM CEST, anthony.l.nguyen@...el.com wrote:
>>
>>
>> On 8/2/2024 12:35 AM, Michal Swiatkowski wrote:
>>> On Fri, Aug 02, 2024 at 08:56:53AM +0200, Jiri Pirko wrote:
>>>> Fri, Aug 02, 2024 at 07:11:48AM CEST, michal.swiatkowski@...ux.intel.com wrote:
>>>>> On Thu, Aug 01, 2024 at 04:32:56PM +0200, Jiri Pirko wrote:
>>>>>> Thu, Aug 01, 2024 at 12:10:11AM CEST, anthony.l.nguyen@...el.com wrote:
>>>>>>> Michal Swiatkowski says:
>>>>>>>
>>>>>>> Currently ice driver does not allow creating more than one networking
>>>>>>> device per physical function. The only way to have more hardware backed
>>>>>>> netdev is to use SR-IOV.
>>>>>>>
>>>>>>> Following patchset adds support for devlink port API. For each new
>>>>>>> pcisf type port, driver allocates new VSI, configures all resources
>>>>>>> needed, including dynamically MSIX vectors, program rules and registers
>>>>>>> new netdev.
>>>>>>>
>>>>>>> This series supports only one Tx/Rx queue pair per subfunction.
>>>>>>>
>>>>>>> Example commands:
>>>>>>> devlink port add pci/0000:31:00.1 flavour pcisf pfnum 1 sfnum 1000
>>>>>>> devlink port function set pci/0000:31:00.1/1 hw_addr 00:00:00:00:03:14
>>>>>>> devlink port function set pci/0000:31:00.1/1 state active
>>>>>>> devlink port function del pci/0000:31:00.1/1
>>>>>>>
>>>>>>> Make the port representor and eswitch code generic to support
>>>>>>> subfunction representor type.
>>>>>>>
>>>>>>> VSI configuration is slightly different between VF and SF. It needs to
>>>>>>> be reflected in the code.
>>>>>>> ---
>>>>>>> v2:
>>>>>>> - Add more recipients
>>>>>>>
>>>>>>> v1: https://lore.kernel.org/netdev/20240729223431.681842-1-anthony.l.nguyen@intel.com/
>>>>>>
>>>>>> I'm confused a bit. This is certainly not v2. I replied to couple
>>>>>> versions before. There is no changelog. Hard to track changes :/
>>>>>
>>>>> You can see all changes here:
>>>>> https://lore.kernel.org/netdev/20240606112503.1939759-1-michal.swiatkowski@linux.intel.com/
>>>>>
>>>>> This is pull request from Tony, no changes between it and version from
>>>>> iwl.
>>>>
>>>> Why the changelog can't be here too? It's still the same patchset, isn't
>>>> it?
>>>>
>>>
>>> Correct it is the same patchset. I don't know, I though it is normal
>>> that PR is starting from v1, feels like it was always like that.
>>> Probably Tony is better person to ask about the process here.
>>
>> The previous patches were 'iwl-next', when we send to 'net-next' we reset the
>> versions since it's going to a new list.
> 
> I still see it in the same list. Same patchset.

While it happened for this pull request, this is not always the case. 
For situations like this, I can add a link back to the iwl-next version 
so that it can be easily tracked back.

Thanks,
Tony