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

[Thomas Monjalon <thomas@monjalon.net>]

Any more opinion about removing VF columns from the NIC matrix?

24/03/2020 09:36, Andrew Rybchenko:
> On 3/20/20 2:15 PM, Zhang, Qi Z wrote:
> > From: Thomas Monjalon <thomas@monjalon.net>
> >> 20/03/2020 06:35, Zhang, Qi Z:
> >>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>> 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.