netdev - Re: [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver

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: Thu, 18 May 2023 16:26:24 -0700
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: Emil Tantilov <emil.s.tantilov@...el.com>,
	<intel-wired-lan@...ts.osuosl.org>, <shannon.nelson@....com>,
	<simon.horman@...igine.com>, <leon@...nel.org>, <decot@...gle.com>,
	<willemb@...gle.com>, <jesse.brandeburg@...el.com>,
	<anthony.l.nguyen@...el.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <netdev@...r.kernel.org>, "Singhai,
 Anjali" <anjali.singhai@...el.com>, "Orr, Michael" <michael.orr@...el.com>
Subject: Re: [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver



On 5/18/2023 10:10 AM, Michael S. Tsirkin wrote:
> On Thu, May 18, 2023 at 09:19:31AM -0700, Samudrala, Sridhar wrote:
>>
>>
>> On 5/11/2023 11:34 PM, Michael S. Tsirkin wrote:
>>> On Mon, May 08, 2023 at 12:43:11PM -0700, Emil Tantilov wrote:
>>>> This patch series introduces the Intel Infrastructure Data Path Function
>>>> (IDPF) driver. It is used for both physical and virtual functions. Except
>>>> for some of the device operations the rest of the functionality is the
>>>> same for both PF and VF. IDPF uses virtchnl version2 opcodes and
>>>> structures defined in the virtchnl2 header file which helps the driver
>>>> to learn the capabilities and register offsets from the device
>>>> Control Plane (CP) instead of assuming the default values.
>>>
>>> So, is this for merge in the next cycle?  Should this be an RFC rather?
>>> It seems unlikely that the IDPF specification will be finalized by that
>>> time - how are you going to handle any specification changes?
>>
>> Yes. we would like this driver to be merged in the next cycle(6.5).
>> Based on the community feedback on v1 version of the driver, we removed all
>> references to OASIS standard and at this time this is an intel vendor
>> driver.
>>
>> Links to v1 and v2 discussion threads
>> https://lore.kernel.org/netdev/20230329140404.1647925-1-pavan.kumar.linga@intel.com/
>> https://lore.kernel.org/netdev/20230411011354.2619359-1-pavan.kumar.linga@intel.com/
>>
>> The v1->v2 change log reflects this update.
>> v1 --> v2: link [1]
>>   * removed the OASIS reference in the commit message to make it clear
>>     that this is an Intel vendor specific driver
> 
> Yes this makes sense.
> 
> 
>> Any IDPF specification updates would be handled as part of the changes that
>> would be required to make this a common standards driver.
> 
> 
> So my question is, would it make sense to update Kconfig and module name
> to be "ipu" or if you prefer "intel-idpf" to make it clear this is
> currently an Intel vendor specific driver?  And then when you make it a
> common standards driver rename it to idpf?  The point being to help make
> sure users are not confused about whether they got a driver with
> or without IDPF updates. It's not critical I guess but seems like a good
> idea. WDYT?

It would be more disruptive to change the name of the driver. We can 
update the pci device table, module description and possibly driver 
version when we are ready to make this a standard driver.
So we would prefer not changing the driver name.