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

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

Date: Sun, 21 May 2023 19:54:55 -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/21/2023 2:21 AM, Michael S. Tsirkin wrote:
> On Fri, May 19, 2023 at 10:36:00AM -0700, Samudrala, Sridhar wrote:
>>
>>
>> On 5/18/2023 10:49 PM, Michael S. Tsirkin wrote:
>>> On Thu, May 18, 2023 at 04:26:24PM -0700, Samudrala, Sridhar wrote:
>>>>
>>>>
>>>> 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.
>>>
>>> Kconfig entry and description too?
>>>
>>
>> The current Kconfig entry has Intel references.
>>
>> +config IDPF
>> +	tristate "Intel(R) Infrastructure Data Path Function Support"
>> +	depends on PCI_MSI
>> +	select DIMLIB
>> +	help
>> +	  This driver supports Intel(R) Infrastructure Processing Unit (IPU)
>> +	  devices.
>>
>> It can be updated with Intel references removed when the spec becomes
>> standard and meets the community requirements.
> 
> Right, name says IDPF support help says IPU support.
> Also config does not match name.
> 
> Do you want:
> 
> 
> config INTEL_IDPF
> 	tristate "Intel(R) Infrastructure Data Path Function Support"
> 
> and should help say
> 
> 	  This driver supports Intel(R) Infrastructure Data Path Function
> 	  devices.
> ?

IDPF Kconfig entry is listed only when CONFIG_NET_VENDOR_INTEL is 
selected. So I think adding INTEL_ prefix to the config entry under 
Intel devices sounds redundant.

But we can definitely update the help section as you suggested to match 
with the name.