[dpdk-dev] [PATCH 0/3] refresh NIC features matrix

[Andrew Rybchenko]

On 3/20/20 2:15 PM, Zhang, Qi Z wrote:
> 
> 
>> -----Original Message-----
>> From: Thomas Monjalon <thomas at monjalon.net>
>> Sent: Friday, March 20, 2020 6:45 PM
>> To: Zhang, Qi Z <qi.z.zhang at intel.com>
>> Cc: dev at dpdk.org; rahul.lakkireddy at chelsio.com; Wang, Xiao W
>> <xiao.w.wang at intel.com>; xavier.huwei at huawei.com; Xing, Beilei
>> <beilei.xing at intel.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Yang, Qiming
>> <qiming.yang at intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>;
>> jerinj at marvell.com; rmody at marvell.com; shshaikh at marvell.com;
>> maxime.coquelin at redhat.com; Ye, Xiaolong <xiaolong.ye at intel.com>
>> Subject: Re: [PATCH 0/3] refresh NIC features matrix
>>
>> 20/03/2020 06:35, Zhang, Qi Z:
>>> Hi Thomas:
>>>
>>> From: Thomas Monjalon <thomas at monjalon.net>
>>>>
>>>> This series aims to clean-up the big table of ethdev features:
>>>>   http://doc.dpdk.org/guides/nics/overview.html#id1
>>>>
>>>> We could reorganize the information in this table, maybe split it or
>>>> add/remove some rows.
>>>> Before going to such reorganization, we should clean it up.
>>>>
>>>> The first patch is fixing the look & size of the table with recent sphinx.
>>>>
>>>> The second and third patches are removing 8 columns which are
>>>> clearly
>>>> unneeded:
>>>>   - bnx2x_vf
>>>>   - bonding
>>>>   - kni
>>>>   - nfp_vf
>>>>   - null
>>>>   - ring
>>>>   - softnic
>>>>   - vdev_netvsc
>>>>
>>>> More columns can be removed by merging PF/VF and vector datapaths.
>>>> If a feature cannot be supported in all cases, it should be marked
>>>> as partially supported (P).
>>>> If a feature is PF-specific (like flow control), that's OK to mark
>>>> it fully supported because it's obviously impossible for VF.
>>>> There are also some features which were probably marked in some
>>>> columns and missed in its VF or vector counterpart.
>>>> Please work to merge and drop these 16 columns:
>>>>   - cxgbevf
>>>>   - fm10k_vf
>>>>   - hns3_vf
>>>>   - i40e_vec
>>>>   - i40e_vf
>>>>   - i40e_vf_vec
>>>>   - iavf_vec
>>>>   - ice_vec
>>>>   - igb_vf
>>>>   - ixgbe_vec
>>>>   - ixgbe_vf
>>>>   - ixgbe_vf_vec
>>>>   - octeontx2_vec
>>>>   - octeontx2_vf
>>>>   - qede_vf
>>>>   - virtio_vec
>>>>
>>>> The total gain is to reduce the table size from 71 to 47 columns.
>>>
>>> I agree to remove all the column with "vec", since vector PMD can be
>> regarded as a feature of the a PMD.
>>> But I'm not sure if it is a good idea to merge VF and PF into one column.
>>> From my view, for intel device, VF driver and PF driver just share the code,
>> but they actually are running at two different context.
>>> And likely they will support different feature, merge into one column may
>> confuse our customer if they want to understand what exactly the PMD
>> support.
>>
>> I understand you have 2 different datapaths.
>> My arguments are:
>> 	- it is the same NIC
> 
> Yes, but one device can be polymorphic, ideally i40e and i40evf could be in two different folder, and the common part can be a library in driver/common/i40e.

For me, it does not sound like a good idea. Too many folders on
the first level does not look nice. Should we go Linux way and
group by vendor? Too early? However, it is not directly
related to the topic.

>> 	- you cannot summarize everything in a table
>> 	- we have two many columns to make it readable
> 
> I don't think columns number is critical, typically user just need to focus on the first column and the specific driver's column, 

Too many columns still makes it harder to read/analyze. I think
the main goal of the table is too help making NIC choice to
be installed in a server and you can't make a choice between
PF and VF. Difference between PF and VF capabilities is
a separate story and out-of-scope of the table.
We have a new driver(s) in each DPDK release and table is
already big and will grow more and more.

> I guess it may not a big challenge to enable some filter by front end web technique?
>
>> I think the right solution is mark features as partially available (P), and give
>> details in the driver guide documentation.
>>
>> Can you please, at least, remove the "vec" columns, as a first step?
> 
> Sure, as I said, I agree to remove "vec".
> 
> Thanks
> Qi
> 
>> Thanks
>>
>