As to this API implementation in i40e, there are some common codes should be included in this patch.
> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Friday, October 17, 2014 5:08 PM > To: Wu, Jingjing > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition > > 2014-10-17 07:29, Jingjing Wu: > > Define new APIs to support configure multi-kind filters using same > > APIs, instead of creating each API set for each kind of filter. > > - rte_eth_dev_filter_supported > > - rte_eth_dev_filter_ctrl > > > > Filter types, operations, and structures are defined specifically in > > new header file lib/librte_eth/rte_dev_ctrl.h. > > > > As to the implementation discussion, please refer to > > http://dpdk.org/ml/archives/dev/2014-September/005179.html > [...] > > --- /dev/null > > +++ b/lib/librte_ether/rte_eth_ctrl.h > > Why this name? I think we can reserve this file for filtering API. > So rte_eth_rx_filter.h would be more appropriate. > > > +/** > > + * All generic operations to filters > > + */ > > rewording: "Generic operations on filters" > Could you elaborate on "generic"? What would mean "specific"? > > > +enum rte_filter_op { > > + RTE_ETH_FILTER_OP_NONE = 0, > > + /**< used to check whether the type filter is supported */ > > + RTE_ETH_FILTER_OP_ADD, /**< add filter entry */ > > + RTE_ETH_FILTER_OP_UPDATE, /**< update filter entry */ > > + RTE_ETH_FILTER_OP_DELETE, /**< delete filter entry */ > > + RTE_ETH_FILTER_OP_FLUSH, /**< flush all entries */ > > + RTE_ETH_FILTER_OP_GET, /**< get filter entry */ > > + RTE_ETH_FILTER_OP_SET, /**< configurations */ > > + RTE_ETH_FILTER_OP_GET_INFO, > > Could we remove "OP", except for OP_NONE and OP_MAX? > > > + /**< get information of filter, such as status or statistics */ > > + RTE_ETH_FILTER_OP_MAX, > > +}; > > > +int > > +rte_eth_dev_filter_supported(uint8_t port_id, enum rte_filter_type > > +filter_type) > > This function is really important for compatibility. Good > > > +/** > > + * Take operations to assigned filter type on an Ethernet device. > > + * All the supported operations and filter types are defined in > 'rte_eth_ctrl.h'. > > + * > > + * @param port_id > > + * The port identifier of the Ethernet device. > > + * @param filter_type > > + * filter type. > > + * @param filter_op > > + * The operation taken to assigned filter. > > Rewording: "Type of operation" > > > + * @param arg > > + * A pointer to arguments defined specifically for the operation. > > Actually, arg is specific to the filter type. > Could it be also specific to the operation. Maybe. > I think we will have to explicitly specify which operations can be used with > each structure (in its comments). > > > + * @return > > + * - (0) if successful. > > + * - (-ENOTSUP) if hardware doesn't support. > > + * - (-ENODEV) if *port_id* invalid. > > + * - others depends on the specific operations implementation. > > + */ > > +int rte_eth_dev_filter_ctrl(uint8_t port_id, enum rte_filter_type > filter_type, > > + enum rte_filter_op filter_op, void *arg); > > Could we add rx in the name? rte_eth_dev_rx_filter_ctrl If you agree with > this naming, it should be added in several other places. > > This API is quite simple (which is a good thing). > Let's see how it fits when integrating filtering features. > If something appears to be wrongly designed when integrating a feature or > when implementing it in a driver, feel free to fix the API. > > Thanks > -- > Thomas
