[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 28, 2014 11:56 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl
> 
> 2014-08-28 03:30, Wu, Jingjing:
> > We want to implement several common API for NIC specific features,
> > to avoid creating quite a lot of ops in 'struct eth_dev_ops'.
> > The idea came from ioctl.
> 
> The approach can be interesting.
> 
> > Because about flow director feature, there is large gap between i40e
> > and ixgbe. The existed flow director APIs looks specific to IXGBE,
> > so I choose this new API to implement i40e's flow director feature.
> 
> The API is not OK for you so you create another one.
> I'm OK to change APIs but you should remove the old one, or at least,
> implement your new API in existing drivers to allow deprecation of the
> old API.
> I think it would help if you start by doing ixgbe work and then apply it
> to i40e.
> 
> > The API is like below:
> > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,
> > 						  enum rte_eth_command cmd,
> > 						  void *arg);
> > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains
> > the definition about structures specific to i40e, linked to the arg
> > parameters above.
> > Define a head file called rte_eth_features.h in lib/librte_ether, which
> > contains the commands' definition linked to cmd parameters above.
> 
> Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?

As I remember the long term idea was
(Jingjing please correct me, if I am wrong here):

Keep rte_ethdev.h for generic API.
Put features specific for different NICs into rte_eth_features.h 
To make things clearer and avoid polluting of rte_ethdev.h.

Provide API for the upper layer to query list of specific features(commands) supported by the underlying device.
Something like: 
rte_eth_dev_get_rx_filter_supported(port, ...);

And ioctl-type API to configure HW specific features: 
rte_eth_dev_rx_classification_filter_ctl(port, cmd, cmd_spedific_arg);

So, instead of application knows in advance "which specific NIC it is using",
application would query which features/commannds the NIC provides and then configure them appropriately.

> 
> > And if user want to use i40e specific features, then the head file
> > rte_i40e.h need to be included user's application, for example, test-pmd.
> > And user can encode these structures and call XXX_ctl API to configure
> > their features.
> 
> OK, but the question is to know what is a specific feature?
> I don't think flow director is a specific feature. We shouldn't have
> to care if port is i40e or ixgbe to setup flow director.
> Is it possible to have a common API and maybe an inheritance of the
> common structure with PMD specific fields?
> 
> Example:
> 
> struct fdir_entry {
> 	fdir_input input;
> 	fdir_action action;
> 	enum rte_driver driver;
> };
> fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};
> filter_ctl(port, FDIR_RULE_ADD, fdir_entry);
> 
> struct i40e_fdir_entry {
> 	struct fdir_entry generic;
> 	i40e_fdir_input i40e_input;
> };
> 
> So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.
> 
> It's just an idea, comments are welcome.
> 
> --
> Thomas