Hi, Thomas Thanks for your reply.
About your first concern: The pool field is used in virtualization scenario. It is acting as one of input set during filter matching in ixgbe. My patch didn't consider the virtualization scenario in generic filter feature. Because in 82599 datasheet, it is recommended to assign rx queues not used by DCB/RSS, that is virtualization without RSS and DCB mode. For this mode, current DPDK version makes the number of queue to 1 by default in IOV mode. So in this case it makes no sense make pool as a input set and the rx queue also need to be set to in this pool, so just keep the consistent with flow director who also ignore it in previous version. And further E1000/Niantic/Fortville have different definitions for VF, we need to think how to define it more generic. And even just need offer pool number in configuration of the filters as what Vladimir did, it also need to verify the interworking with Virtualization for different kinds of NICs, and the interworking with DCB and RSS which is not recommended in 82599's datasheet. So I think it will be a good choice to implement generic filter interworking with virtualization in future patch. If there is any volunteer to send patch for support this concern later, it will be also cool. About your second concern: I will send out a new version for that soon. -----Original Message----- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Wednesday, June 11, 2014 11:45 PM To: Wu, Jingjing Cc: dev at dpdk.org; Vladimir Medvedkin Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi Jingjing, Please reply below the question. 2014-05-28 01:12, Wu, Jingjing: > You are discussing whether the APIs provide for NIC filters is generic > or not. About that we can use same API for a type of filter. For > example, if we want to configure ethertype filter, we can use the same > API, no matter the NIC is 82580, i350, 82576 or 82599. We think these > NICs may be most common used. I was wondering if this API can apply to non-Intel devices. But nobody talked about it. So let's forget it. My main concern is that Vladimir Medvedkin suggested another API and I'd like you give your opinion about it: http://dpdk.org/ml/archives/dev/2014-June/003053.html It offers pool number in configuration of the filters. Last comment: patches would be more pleasant to read with right alignment and spaces in comments. This is an extract to illustrate what I'm talking about: + uint16_t priority; /**< used when more than one filter matches */ + uint8_t dst_port_mask : 1, /**<if mask is 1b, means not compare*/ + protocol_mask : 1; Thanks -- Thomas
