[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
--- the v2 patchset changes: --- add NIC filter support for 82576 --- rework for code rule warning if using git apply to apply patch A generic filter mechanism for handling special packet is required. It will allow filters to be set in HW when available so that specific packet may be filtered by NICs to specific descriptor queues for processing. Currently only Flow Director for Intel's 10GbE 82599 devices is available. Other types of filter are not support. NIC filters list below are implemented in this patchset: ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and i350 ethertype filter, syn filter, 5tuple filter for 82576 ethertype filter, syn filter and 5tuple filter for 82599 jingjing.wu (4): add ethdev APIs for NIC filters of generic filter add igb NIC filters of generic filter feature add ixgbe NIC filters of generic filter feature add commands in testpmd for NIC filters app/test-pmd/cmdline.c | 907 +++- app/test-pmd/config.c | 145 ++ app/test-pmd/testpmd.h | 6 + lib/librte_ether/rte_ethdev.c | 281 +++ lib/librte_ether/rte_ethdev.h | 421 - lib/librte_pmd_e1000/e1000_ethdev.h | 53 +++ lib/librte_pmd_e1000/igb_ethdev.c | 745 + lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 409 lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 33 ++ 9 files changed, 2998 insertions(+), 2 deletions(-) -- 1.8.1.4
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi Jingjing, 2014-05-24 09:37, Jingjing Wu: > A generic filter mechanism for handling special packet is required. > It will allow filters to be set in HW when available so that specific > packet may be filtered by NICs to specific descriptor queues for > processing. Currently only Flow Director for Intel's 10GbE 82599 > devices is available. Other types of filter are not support. > NIC filters list below are implemented in this patchset: > ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and > i350 ethertype filter, syn filter, 5tuple filter for 82576 > ethertype filter, syn filter and 5tuple filter for 82599 I'd like we have a discussion about how this API is generic enough. I think many people would like to integrate drivers for other NICs in DPDK and I'd hate to see a global rework of this API because we haven't tried to think about it before. First, is there someone in the mailing list who knows other hardware which could fit in this filtering feature? Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi, Thomas This patch is mainly about multiple NIC filters implement. It has close relationship with NICs. As the patch says: NIC filters list below are implemented in this patchset: ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and i350 ethertype filter, syn filter, 5tuple filter for 82576 ethertype filter, syn filter and 5tuple filter for 82599 The same type filter uses the same API for the NICs list above. About the generic filter feature, how to define the "generic" is still in discussing, and not included in this patch. These NIC filters implemented in this patch are first step. Even without generic, it also provides a way to configure these NIC filters to hardware in DPDK PMD. -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Wednesday, May 28, 2014 7:22 AM To: Wu, Jingjing Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi Jingjing, 2014-05-24 09:37, Jingjing Wu: > A generic filter mechanism for handling special packet is required. > It will allow filters to be set in HW when available so that specific > packet may be filtered by NICs to specific descriptor queues for > processing. Currently only Flow Director for Intel's 10GbE 82599 > devices is available. Other types of filter are not support. > NIC filters list below are implemented in this patchset: > ethertype filter, syn filter, 2tuple filter and flex filter for > 82580 and > i350 ethertype filter, syn filter, 5tuple filter for 82576 > ethertype filter, syn filter and 5tuple filter for 82599 I'd like we have a discussion about how this API is generic enough. I think many people would like to integrate drivers for other NICs in DPDK and I'd hate to see a global rework of this API because we haven't tried to think about it before. First, is there someone in the mailing list who knows other hardware which could fit in this filtering feature? Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi, Thomas The generic you said may be different from I mentioned in last mail. 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. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wu, Jingjing Sent: Wednesday, May 28, 2014 8:53 AM To: Thomas Monjalon Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi, Thomas This patch is mainly about multiple NIC filters implement. It has close relationship with NICs. As the patch says: NIC filters list below are implemented in this patchset: ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and i350 ethertype filter, syn filter, 5tuple filter for 82576 ethertype filter, syn filter and 5tuple filter for 82599 The same type filter uses the same API for the NICs list above. About the generic filter feature, how to define the "generic" is still in discussing, and not included in this patch. These NIC filters implemented in this patch are first step. Even without generic, it also provides a way to configure these NIC filters to hardware in DPDK PMD. -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Wednesday, May 28, 2014 7:22 AM To: Wu, Jingjing Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi Jingjing, 2014-05-24 09:37, Jingjing Wu: > A generic filter mechanism for handling special packet is required. > It will allow filters to be set in HW when available so that specific > packet may be filtered by NICs to specific descriptor queues for > processing. Currently only Flow Director for Intel's 10GbE 82599 > devices is available. Other types of filter are not support. > NIC filters list below are implemented in this patchset: > ethertype filter, syn filter, 2tuple filter and flex filter for > 82580 and > i350 ethertype filter, syn filter, 5tuple filter for 82576 > ethertype filter, syn filter and 5tuple filter for 82599 I'd like we have a discussion about how this API is generic enough. I think many people would like to integrate drivers for other NICs in DPDK and I'd hate to see a global rework of this API because we haven't tried to think about it before. First, is there someone in the mailing list who knows other hardware which could fit in this filtering feature? Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Tested-by: Waterman Cao This patch includes 4 files, and has been tested by Intel. Please see information as the following: Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2 Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576 We verified ethertype filter, 2-tuple filter, 5-tuple filter, flex filter and SYN filter with different NICs. Total casesPassed Failed 18 16 2 Failure only related to priority of filter, no impact on functionality. Example: Show how to distribute specific packet to assigned queue Please launch testpmd firstly, then run the following command: ---add syn filter --- testpmd> add_syn_filter (port_id) priority (high|low) queue (queue_id) ---get syn filter info --- testpmd> get_syn_filter (port_id) ---remove syn filter --- testpmd> remove_syn_filter (port_id)
[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, /**
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
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, /**
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
> 2014-06-11 17:45, Thomas Monjalon: > > 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. 2014-06-12 08:08, Wu, Jingjing: > 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. Vladimir, do you agree with this analysis? As you suggested another implementation, I need you acknowledgment for this patchset to be integrated. Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi all, The 82599 datasheet (p. 284 and p.287) has only recommendations and only when possible about assign rx queue not used by RSS/DCB. I do not see any serious restrictions do not assign the rx queue used by RSS/DCB. For cases with only 1 queue if I understand correctly this patch http://dpdk.org/ml/archives/dev/2014-May/002589.html we can init second queue in pool and assign it by filter. In *ETH_MQ_RX_VMDQ_ONLY* mode init all possible queues (even if hardware route packets to zero queue in pools) so there no problem. Moreover, it is not necesary for rx queue to be set in the same pool. About genericity. I agree with Jingjing, different controllers have different definitions for pools or VFs. And it is only Intel controllers! It is very hard to predict hardware implementation. For example for Fortville I can not find 5-tuple filters at all. API. I have several remarks. 1. You use rx_queue as separate arg. For example: rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t rx_queue) rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t *rx_queue) you can move uint8_t rx_queue into struct rte_ethertype_filter *filter. 2. In SYN filter: rte_eth_dev_add_syn_filter(uint8_t port_id, uint8_t high_pri, uint8_t rx_queue) rte_eth_dev_get_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) In first ADD func you alloc struct rte_syn_filter inside func, but in GET func you have to alloc struct rte_syn_filter in your app. May be better to do rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) ? So, Jingjing made a lot of work, much more then I (igb filters, testpmd commands). It works the same as mine (not counting pools logic), so let's integrate it (it's will be great if jingjing change api according to my remarks). Regards, Vladimir 2014-06-12 19:36 GMT+04:00 Thomas Monjalon : > > 2014-06-11 17:45, Thomas Monjalon: > > > 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. > > 2014-06-12 08:08, Wu, Jingjing: > > 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. > > Vladimir, do you agree with this analysis? > As you suggested another implementation, I need you acknowledgment for this > patchset to be integrated. > > Thanks > -- > Thomas >
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi, Vladimir Thanks a lot for your remarks. Yes, your understanding is correct, in non-IOV mode, we can use 64pool, per pool can has 2 queues when ETH_MQ_RX_VMDQ_ONLY. While in IOV mode, current DPDK version makes the number of queue to 1 by default. The pools logic makes sense, but I didn?t consider it globally with the thinking we can do it in future. I will be great if you can generate a new patch based on mine. Or we can discuss it further? Due to it is close to the feature deliver time now and much verification work for it, it may not possible to add it in this patch. In API About your first remark, the reason why I didn?t put the queue in the filter structure is that the filter contains the fields used for comparison and the queue is acted as result, and another concern is to keep consistent with flow director?s implementation. About your second remark, I will accept it and integrate the change to patch in new version. Do your agree my proposal? From: Vladimir Medvedkin [mailto:medvedk...@gmail.com] Sent: Friday, June 13, 2014 7:52 PM To: Thomas Monjalon Cc: Wu, Jingjing; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi all, The 82599 datasheet (p. 284 and p.287) has only recommendations and only when possible about assign rx queue not used by RSS/DCB. I do not see any serious restrictions do not assign the rx queue used by RSS/DCB. For cases with only 1 queue if I understand correctly this patch http://dpdk.org/ml/archives/dev/2014-May/002589.html we can init second queue in pool and assign it by filter. In ETH_MQ_RX_VMDQ_ONLY mode init all possible queues (even if hardware route packets to zero queue in pools) so there no problem. Moreover, it is not necesary for rx queue to be set in the same pool. About genericity. I agree with Jingjing, different controllers have different definitions for pools or VFs. And it is only Intel controllers! It is very hard to predict hardware implementation. For example for Fortville I can not find 5-tuple filters at all. API. I have several remarks. 1. You use rx_queue as separate arg. For example: rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t rx_queue) rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t *rx_queue) you can move uint8_t rx_queue into struct rte_ethertype_filter *filter. 2. In SYN filter: rte_eth_dev_add_syn_filter(uint8_t port_id, uint8_t high_pri, uint8_t rx_queue) rte_eth_dev_get_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) In first ADD func you alloc struct rte_syn_filter inside func, but in GET func you have to alloc struct rte_syn_filter in your app. May be better to do rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) ? So, Jingjing made a lot of work, much more then I (igb filters, testpmd commands). It works the same as mine (not counting pools logic), so let's integrate it (it's will be great if jingjing change api according to my remarks). Regards, Vladimir 2014-06-12 19:36 GMT+04:00 Thomas Monjalon mailto:thomas.monjalon at 6wind.com>>: > 2014-06-11 17:45, Thomas Monjalon: > > 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. 2014-06-12 08:08, Wu, Jingjing: > 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. Vladimir, do you agree with this analysis? As you suggested another implementation, I need you acknowledgment for this patchset to be integrated. Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi Jingjing, Yes, I agree. I have one more remark. It is about type of rx_queue arg. Now it is uint8_t. I think we have to change it to uint16_t because for Fortville NIC it is not enough. Quote fro the datasheet: A PF VSI (Virtual Station Interfaces aka virtual NICs) can allocate and use up to 1536 LQPs (LAN queue pairs). Regards, Vladimir 2014-06-13 18:12 GMT+04:00 Wu, Jingjing : > Hi, Vladimir > > > > Thanks a lot for your remarks. > > > > Yes, your understanding is correct, in non-IOV mode, we can use 64pool, > per pool can has 2 queues when ETH_MQ_RX_VMDQ_ONLY. While in IOV mode, > current DPDK version makes the number of queue to 1 by default. The pools > logic makes sense, but I didn?t consider it globally with the thinking we > can do it in future. I will be great if you can generate a new patch based > on mine. Or we can discuss it further? Due to it is close to the feature > deliver time now and much verification work for it, it may not possible to > add it in this patch. > > > > In API > > About your first remark, the reason why I didn?t put the queue in the > filter structure is that the filter contains the fields used for comparison > and the queue is acted as result, and another concern is to keep consistent > with flow director?s implementation. > > About your second remark, I will accept it and integrate the change to > patch in new version. > > > > Do your agree my proposal? > > > > > > *From:* Vladimir Medvedkin [mailto:medvedkinv at gmail.com] > *Sent:* Friday, June 13, 2014 7:52 PM > *To:* Thomas Monjalon > *Cc:* Wu, Jingjing; dev at dpdk.org > > *Subject:* Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic > filter > > > > Hi all, > > The 82599 datasheet (p. 284 and p.287) has only recommendations and only > when possible about assign rx queue not used by RSS/DCB. I do not see any > serious restrictions do not assign the rx queue used by RSS/DCB. > > For cases with only 1 queue if I understand correctly this patch > http://dpdk.org/ml/archives/dev/2014-May/002589.html we can init second > queue in pool and assign it by filter. In *ETH_MQ_RX_VMDQ_ONLY* mode > init all possible queues (even if hardware route packets to zero queue in > pools) so there no problem. Moreover, it is not necesary for rx queue to be > set in the same pool. > > > About genericity. I agree with Jingjing, different controllers have > different definitions for pools or VFs. And it is only Intel controllers! > It is very hard to predict hardware implementation. For example for > Fortville I can not find 5-tuple filters at all. > > > > API. I have several remarks. > > 1. You use rx_queue as separate arg. For example: > > rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index, struct > rte_ethertype_filter *filter, uint8_t rx_queue) > rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index, struct > rte_ethertype_filter *filter, uint8_t *rx_queue) > > you can move uint8_t rx_queue into struct rte_ethertype_filter *filter. > > 2. In SYN filter: > rte_eth_dev_add_syn_filter(uint8_t port_id, uint8_t high_pri, uint8_t > rx_queue) > rte_eth_dev_get_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, > uint8_t *rx_queue) > > In first ADD func you alloc struct rte_syn_filter inside func, but in GET > func you have to alloc struct rte_syn_filter in your app. May be better to > do > rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, > uint8_t *rx_queue) ? > > > > So, Jingjing made a lot of work, much more then I (igb filters, testpmd > commands). It works the same as mine (not counting pools logic), so let's > integrate it (it's will be great if jingjing change api according to my > remarks). > > > > Regards, > > Vladimir > > > > 2014-06-12 19:36 GMT+04:00 Thomas Monjalon : > > > 2014-06-11 17:45, Thomas Monjalon: > > > > 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. > > 2014-06-12 08:08, Wu, Jingjing: > > > 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
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi, Vladimir Yes, for Fortville, uint8_t is not enough, it was also the concern is to keep consistent with flow director?s implementation. But I agree that we need to change. Let make an agreement like: I will make change for the remarks from you. One is the change the type of rx_queue to uint16_t. The other is change API like ?rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint16_t rx_queue)?. And about the pool and virtualization case, maybe you will send a new patch about it, maybe me. Whatever, just leave it in future, not include in this patch. Thank you! Jingjing From: Vladimir Medvedkin [mailto:medvedk...@gmail.com] Sent: Saturday, June 14, 2014 12:19 AM To: Wu, Jingjing Cc: Thomas Monjalon; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi Jingjing, Yes, I agree. I have one more remark. It is about type of rx_queue arg. Now it is uint8_t. I think we have to change it to uint16_t because for Fortville NIC it is not enough. Quote fro the datasheet: A PF VSI (Virtual Station Interfaces aka virtual NICs) can allocate and use up to 1536 LQPs (LAN queue pairs). Regards, Vladimir 2014-06-13 18:12 GMT+04:00 Wu, Jingjing mailto:jingjing.wu at intel.com>>: Hi, Vladimir Thanks a lot for your remarks. Yes, your understanding is correct, in non-IOV mode, we can use 64pool, per pool can has 2 queues when ETH_MQ_RX_VMDQ_ONLY. While in IOV mode, current DPDK version makes the number of queue to 1 by default. The pools logic makes sense, but I didn?t consider it globally with the thinking we can do it in future. I will be great if you can generate a new patch based on mine. Or we can discuss it further? Due to it is close to the feature deliver time now and much verification work for it, it may not possible to add it in this patch. In API About your first remark, the reason why I didn?t put the queue in the filter structure is that the filter contains the fields used for comparison and the queue is acted as result, and another concern is to keep consistent with flow director?s implementation. About your second remark, I will accept it and integrate the change to patch in new version. Do your agree my proposal? From: Vladimir Medvedkin [mailto:medvedkinv at gmail.com<mailto:medvedk...@gmail.com>] Sent: Friday, June 13, 2014 7:52 PM To: Thomas Monjalon Cc: Wu, Jingjing; dev at dpdk.org<mailto:dev at dpdk.org> Subject: Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter Hi all, The 82599 datasheet (p. 284 and p.287) has only recommendations and only when possible about assign rx queue not used by RSS/DCB. I do not see any serious restrictions do not assign the rx queue used by RSS/DCB. For cases with only 1 queue if I understand correctly this patch http://dpdk.org/ml/archives/dev/2014-May/002589.html we can init second queue in pool and assign it by filter. In ETH_MQ_RX_VMDQ_ONLY mode init all possible queues (even if hardware route packets to zero queue in pools) so there no problem. Moreover, it is not necesary for rx queue to be set in the same pool. About genericity. I agree with Jingjing, different controllers have different definitions for pools or VFs. And it is only Intel controllers! It is very hard to predict hardware implementation. For example for Fortville I can not find 5-tuple filters at all. API. I have several remarks. 1. You use rx_queue as separate arg. For example: rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t rx_queue) rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index, struct rte_ethertype_filter *filter, uint8_t *rx_queue) you can move uint8_t rx_queue into struct rte_ethertype_filter *filter. 2. In SYN filter: rte_eth_dev_add_syn_filter(uint8_t port_id, uint8_t high_pri, uint8_t rx_queue) rte_eth_dev_get_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) In first ADD func you alloc struct rte_syn_filter inside func, but in GET func you have to alloc struct rte_syn_filter in your app. May be better to do rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, uint8_t *rx_queue) ? So, Jingjing made a lot of work, much more then I (igb filters, testpmd commands). It works the same as mine (not counting pools logic), so let's integrate it (it's will be great if jingjing change api according to my remarks). Regards, Vladimir 2014-06-12 19:36 GMT+04:00 Thomas Monjalon mailto:thomas.monjalon at 6wind.com>>: > 2014-06-11 17:45, Thomas Monjalon: > > 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. 2014-06-12 08:08, Wu, Jingjing: > The pool field is used in virt
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi Jingjing, Ok! Let's get back to this patch after 1.7 release. Thanks! Regards, Vladimir 2014-06-14 5:00 GMT+04:00 Wu, Jingjing : > Hi, Vladimir > > > > Yes, for Fortville, uint8_t is not enough, it was also the concern is to > keep consistent with flow director?s implementation. But I agree that we > need to change. > > > > Let make an agreement like: > > > > I will make change for the remarks from you. One is the change the type of > rx_queue to uint16_t. The other is change API like > ?rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, > uint16_t rx_queue)?. > > > > And about the pool and virtualization case, maybe you will send a new > patch about it, maybe me. Whatever, just leave it in future, not include > in this patch. > > > > Thank you! > > Jingjing > > > > *From:* Vladimir Medvedkin [mailto:medvedkinv at gmail.com] > *Sent:* Saturday, June 14, 2014 12:19 AM > *To:* Wu, Jingjing > *Cc:* Thomas Monjalon; dev at dpdk.org > > *Subject:* Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic > filter > > > > Hi Jingjing, > > Yes, I agree. > I have one more remark. It is about type of rx_queue arg. Now it is > uint8_t. I think we have to change it to uint16_t because for Fortville NIC > it is not enough. Quote fro the datasheet: > A PF VSI (Virtual Station Interfaces aka virtual NICs) can allocate and > use up to 1536 LQPs (LAN queue pairs). > > Regards, > > Vladimir > > > > 2014-06-13 18:12 GMT+04:00 Wu, Jingjing : > > Hi, Vladimir > > > > Thanks a lot for your remarks. > > > > Yes, your understanding is correct, in non-IOV mode, we can use 64pool, > per pool can has 2 queues when ETH_MQ_RX_VMDQ_ONLY. While in IOV mode, > current DPDK version makes the number of queue to 1 by default. The pools > logic makes sense, but I didn?t consider it globally with the thinking we > can do it in future. I will be great if you can generate a new patch based > on mine. Or we can discuss it further? Due to it is close to the feature > deliver time now and much verification work for it, it may not possible to > add it in this patch. > > > > In API > > About your first remark, the reason why I didn?t put the queue in the > filter structure is that the filter contains the fields used for comparison > and the queue is acted as result, and another concern is to keep consistent > with flow director?s implementation. > > About your second remark, I will accept it and integrate the change to > patch in new version. > > > > Do your agree my proposal? > > > > > > *From:* Vladimir Medvedkin [mailto:medvedkinv at gmail.com] > *Sent:* Friday, June 13, 2014 7:52 PM > *To:* Thomas Monjalon > *Cc:* Wu, Jingjing; dev at dpdk.org > > > *Subject:* Re: [dpdk-dev] [PATCH v2 0/4] NIC filters support for generic > filter > > > > Hi all, > > The 82599 datasheet (p. 284 and p.287) has only recommendations and only > when possible about assign rx queue not used by RSS/DCB. I do not see any > serious restrictions do not assign the rx queue used by RSS/DCB. > > For cases with only 1 queue if I understand correctly this patch > http://dpdk.org/ml/archives/dev/2014-May/002589.html we can init second > queue in pool and assign it by filter. In *ETH_MQ_RX_VMDQ_ONLY* mode > init all possible queues (even if hardware route packets to zero queue in > pools) so there no problem. Moreover, it is not necesary for rx queue to be > set in the same pool. > > > About genericity. I agree with Jingjing, different controllers have > different definitions for pools or VFs. And it is only Intel controllers! > It is very hard to predict hardware implementation. For example for > Fortville I can not find 5-tuple filters at all. > > > > API. I have several remarks. > > 1. You use rx_queue as separate arg. For example: > > rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index, struct > rte_ethertype_filter *filter, uint8_t rx_queue) > rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index, struct > rte_ethertype_filter *filter, uint8_t *rx_queue) > > you can move uint8_t rx_queue into struct rte_ethertype_filter *filter. > > 2. In SYN filter: > rte_eth_dev_add_syn_filter(uint8_t port_id, uint8_t high_pri, uint8_t > rx_queue) > rte_eth_dev_get_syn_filter(uint8_t port_id, struct rte_syn_filter *filter, > uint8_t *rx_queue) > > In first ADD func you alloc struct rte_syn_filter inside func, but in GET > func you have to alloc struct rte_syn_filter in your app. May be better to > do > rte_eth_dev_add_syn_filter(uint8_t port_id, struct rte_syn_filter *fi
