> -----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
