[dpdk-dev] [PATCH] net/bnxt: fix to handle default mac address setting when port is stopped
From: Kalesh AP
Driver destroys the vnic when the port is brought down.
Port hw filter setting such as default mac address and
unicast mac filters will be applied when port is started.
Fixed to return success silently for these callbacks
when port is stopped.
Fixes: 39b88344e364 ("net/bnxt: fix enable/disable VLAN filtering")
Cc: sta...@dpdk.org
Reported-by: Stephen Hemminger
Signed-off-by: Kalesh AP
Reviewed-by: Ajit Kumar Khaparde
Reviewed-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_ethdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 18aa313..3c50c2e 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1103,6 +1103,10 @@ static int bnxt_mac_addr_add_op(struct rte_eth_dev
*eth_dev,
return -EINVAL;
}
+ /* Filter settings will get applied when port is started */
+ if (!eth_dev->data->dev_started)
+ return 0;
+
rc = bnxt_add_mac_filter(bp, vnic, mac_addr, index, pool);
return rc;
@@ -2094,6 +2098,10 @@ bnxt_set_default_mac_addr_op(struct rte_eth_dev *dev,
if (rte_is_zero_ether_addr(addr))
return -EINVAL;
+ /* Filter settings will get applied when port is started */
+ if (!dev->data->dev_started)
+ return 0;
+
/* Check if the requested MAC is already added */
if (memcmp(addr, bp->mac_addr, RTE_ETHER_ADDR_LEN) == 0)
return 0;
--
2.10.1
[dpdk-dev] [PATCH] eal: fix log message print for regex
If user passes log-level eal parameter to enable log level based on regex
then in case of error message is being printed for pattern match instead of
regex. Following is the warning message thrown:
Compiling C object
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_options.c.o'.
In function ‘eal_parse_log_level’,
inlined from ‘eal_parse_common_option’ at
../lib/librte_eal/common/eal_common_options.c:1418:7:
../lib/librte_eal/common/eal_common_options.c:1053:4: warning: ‘%s’ directive
argument is null [-Wformat-overflow=]
1053 |fprintf(stderr, "cannot set log level %s,%d\n",
|^~~
1054 | pattern, priority);
| ~~
Fixes: 7f0bb634a140 ("log: add ability to match log type with globbing")
Signed-off-by: Sunil Kumar Kori
---
lib/librte_eal/common/eal_common_options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 75974dd5b..525e51e7d 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -1046,7 +1046,7 @@ eal_parse_log_level(const char *arg)
if (regex) {
if (rte_log_set_level_regexp(regex, priority) < 0) {
fprintf(stderr, "cannot set log level %s,%d\n",
- pattern, priority);
+ regex, priority);
goto fail;
}
if (rte_log_save_regexp(regex, priority) < 0)
--
2.17.1
Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to allowed devices
Hello All, Is there any thought on this ? Otherwise it can be merged. Regards Sunil Kumar Kori >-Original Message- >From: Sunil Kumar Kori >Sent: Thursday, January 23, 2020 2:13 PM >To: Stephen Hemminger ; Jerin Jacob >Kollanukkaran >Subject: FW: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to >allowed devices > >Hello Stephen, > >Can you please look into this patch or provide your thought in this ? So that >it >can be merged within 20.02 release. > >Regards >Sunil Kumar Kori > >-Original Message- >From: Sunil Kumar Kori >Sent: Tuesday, January 21, 2020 2:09 PM >To: Sunil Kumar Kori ; Stephen Hemminger > >Cc: dev@dpdk.org >Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to >allowed devices > >Hello Stephen, >Any suggestions ? > >Regards >Sunil Kumar Kori > >>-Original Message- >>From: dev On Behalf Of Sunil Kumar Kori >>Sent: Tuesday, December 17, 2019 4:30 PM >>To: Stephen Hemminger >>Cc: dev@dpdk.org >>Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus >>scanning to allowed devices >> >> >> >>Regards >>Sunil Kumar Kori >> >>>-Original Message- >>>From: Stephen Hemminger >>>Sent: Monday, December 16, 2019 9:43 PM >>>To: Sunil Kumar Kori >>>Cc: dev@dpdk.org >>>Subject: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: restricted bus scanning >>>to allowed devices >>> >>>External Email >>> >>>-- /* Create dummy pci device to get devargs */ + dummy_dev.addr.domain = >>>matches[i].pc_sel.pc_domain; + dummy_dev.addr.bus = matches[i].pc_sel.pc_bus; + dummy_dev.addr.devid = matches[i].pc_sel.pc_dev; + dummy_dev.addr.function = >>>matches[i].pc_sel.pc_func; + dummy_dev.device.devargs = + >>> pci_devargs_lookup(&dummy_dev); + + /* Check that device should be ignored or not */ + if (pci_ignore_device(&dummy_dev)) + continue; >>> >>>It seems that you are creating dummy_dev as an alternative to passing >>>just the PCI bus/device/function. Wouldn't be easier to just use BDF >>>instead. Dummy arguments on the stack can lead to more corner cases in >>>the future if device subsystem changes. >>Agreed and initially I have implemented using BDF only instead of using >>dummy device. >>But using that approach, I was not able to use existing APIs to get >>devargs and ignore device. >>I had to write almost same functions to solve the purpose. So just to >>avoid having replica of same code, I followed this approach. Please suggest. >>> +/** + * Get the devargs of a PCI device. + * + * @param pci_dev + *PCI device to be validated + * @return + *devargs on succes, NULL otherwise + */ +struct rte_devargs *pci_devargs_lookup(struct rte_pci_device +*pci_dev); >>> >>>Must be marked experimental (or internal). >>>The pci_device should be marked const. >>Okay but If I go with BDF one then this change is not required anyway. >>> >>> + +/** + * Validate whether a pci device should be ignored or not. + * + * @param pci_dev + *PCI device to be validated + * @return + *1 if device is to be ignored, 0 otherwise + */ +bool pci_ignore_device(const struct rte_pci_device *pci_dev); >>> >>>ditto >>ditto
Re: [dpdk-dev] [PATCH v3] regexdev: introduce regexdev subsystem
Hi Ori,
Look forward to your v4:).
Thanks,
Xiang
On Thu, Feb 27, 2020 at 07:31:48AM +, Ori Kam wrote:
> Hi Xiang,
>
> > -Original Message-
> > From: Wang Xiang
> > Sent: Thursday, February 27, 2020 11:26 AM
> > To: Ori Kam
> > Cc: Jerin Jacob ; Jerin Jacob ;
> > dpdk-dev ; Pavan Nikhilesh ;
> > Shahaf Shuler ; Hemant Agrawal
> > ; Opher Reviv ; Alex
> > Rosenbaum ; dov...@marvell.com; Prasun Kapoor
> > ; Nipun Gupta ; Richardson,
> > Bruce ; yang.a.h...@intel.com;
> > harry.ch...@intel.com; gu.ji...@zte.com.cn; shanjia...@chinatelecom.cn;
> > zhangy@chinatelecom.cn; lixin...@huachentel.com; wush...@inspur.com;
> > yuying...@yxlink.com; fanchengg...@sunyainfo.com;
> > davidf...@tencent.com; liuzho...@chinaunicom.cn;
> > zhaoyon...@huawei.com; o...@yunify.com; j...@netgate.com;
> > hongjun...@intel.com; j.bromh...@titan-ic.com; d...@ntop.org;
> > f...@napatech.com; arthur...@lionic.com; Thomas Monjalon
> >
> > Subject: Re: [dpdk-dev] [PATCH v3] regexdev: introduce regexdev subsystem
> >
> > Hi Ori,
> >
> > Thanks for the comments.
> >
> > Hyperscan supports both start_offset and end_offset modes with most
> > users choosing end_offset for rule coverage and performance reasons.
> > I'm OK to have the default behavior with start_offset and len.
> > It'll be good to change RTE_REGEX_DEV_CFG_MATCH_AS_START to
> > RTE_REGEX_DEV_CFG_MATCH_AS_END. For users who need only end_offset,
> > they have to set RTE_REGEX_DEV_CFG_MATCH_AS_END bit. We may also
> > remove
> > RTE_REGEX_DEV_SUPP_MATCH_AS_START if you like.
>
> Since you say that Hyperscan can support both modes,
> What about changing the cap field to RTE_REGEX_DEV_SUPP_MATCH_AS_END?
>
Ack. Looks good to me.
> >
> > One question is related to the consistency of start_offset definition
> > among different solutions, does all solutions return the leftmost
> > start_offset, i.e. for rule: foo.*bar and input: foofoobar, the returned
> > start_offset will be 0 not 3?
> >
> Yes, you are correct,
> In Mellanox case there will be only one result: start_offset 0
>
> > Thanks,
> > Xiang
> >
> > On Wed, Feb 26, 2020 at 08:36:51AM +, Ori Kam wrote:
> > > Hi Xiang,
> > >
> > >
> > > > -Original Message-
> > > > From: dev On Behalf Of Wang Xiang
> > > > Sent: Wednesday, February 26, 2020 11:03 AM
> > > > To: Ori Kam
> > > > Cc: Jerin Jacob ; Jerin Jacob
> > ;
> > > > dpdk-dev ; Pavan Nikhilesh ;
> > > > Shahaf Shuler ; Hemant Agrawal
> > > > ; Opher Reviv ; Alex
> > > > Rosenbaum ; dov...@marvell.com; Prasun Kapoor
> > > > ; Nipun Gupta ;
> > Richardson,
> > > > Bruce ; yang.a.h...@intel.com;
> > > > harry.ch...@intel.com; gu.ji...@zte.com.cn;
> > shanjia...@chinatelecom.cn;
> > > > zhangy@chinatelecom.cn; lixin...@huachentel.com;
> > wush...@inspur.com;
> > > > yuying...@yxlink.com; fanchengg...@sunyainfo.com;
> > > > davidf...@tencent.com; liuzho...@chinaunicom.cn;
> > > > zhaoyon...@huawei.com; o...@yunify.com; j...@netgate.com;
> > > > hongjun...@intel.com; j.bromh...@titan-ic.com; d...@ntop.org;
> > > > f...@napatech.com; arthur...@lionic.com; Thomas Monjalon
> > > >
> > > > Subject: Re: [dpdk-dev] [PATCH v3] regexdev: introduce regexdev
> > > > subsystem
> > > >
> > > > Hi Ori and Jerin,
> > > >
> > > > One comment regarding my concern with len and end_offset problem.
> > > > From open source SW regex library(libpcre, re2 and Hyperscan) and
> > > > Intel's perspective, the matching results returned are always start
> > > > offset and end offset. More importantly, Hyperscan only reports end
> > > > offset
> > > > most of the time.
> > > >
> > > > It'll be good to keep this union as an abstraction and enforce the
> > > > default
> > > > behavior for each solution, i.e. HW solutions doesn't support
> > MATCH_AS_START
> > > > flag at rule compile time. Applications will know the meaning of
> > > > variable at
> > > > rule compile time with the flag so they don't have to do extra check at
> > > > fast
> > path
> > > > run-time matching.
> > > > Welcome for better abstraction ideas.
> > > >
> > >
> > > I don't mind to keep the union as it was in V3, but I would like to
> > > remove the
> > > configuration bit (RTE_REGEX_DEV_CFG_MATCH_AS_START).
> > > Meaning that if the device reports
> > RTE_REGEX_DEV_SUPP_MATCH_AS_START
> > > the result will always be with start_offset and len.
> > >
> > > Best,
> > > Ori
> > >
> > > > Thanks,
> > > > Xiang
> > > >
> > > > > > > > + /**< Starting Byte Position for matched
> > > > > > > > rule. */
> > > > > > > > + RTE_STD_C11
> > > > > > > > + union {
> > > > > > > > + uint16_t len;
> > > > > > > > + /**< Length of match in bytes */
> > > > > > > > + uint16_t end_offset;
> > > > > > > > + /**< The end offset of the
> > > > > > > > match. In case
> > > > > > > > +* MATC
Re: [dpdk-dev] [PATCH v1] net/axgbe: add debug logs
On 2/16/2020 6:49 AM, Kumar, Ravi1 wrote: <...> >> -Original Message- >> From: Namburu, Chandu-babu >> Sent: Tuesday, February 11, 2020 1:50 PM >> To: dev@dpdk.org >> Cc: Kumar, Ravi1 ; Somalapuram, Amaranath >> >> Subject: [PATCH v1] net/axgbe: add debug logs >> >> From: Chandu Babu N >> >> Add debug logs in various modules in axgbe >> >> Signed-off-by: Chandu Babu N > > Acked-by: Ravi Kumar Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [RFC 0/6] New sync modes for ring
On Tue, Feb 25, 2020 at 7:11 PM Ananyev, Konstantin wrote: > We do have a run-time check in our current enqueue()/dequeue implementation. > In fact we support both modes: we have generic > rte_ring_enqueue(/dequeue)_bulk(/burst) > where sync behaviour is determined at runtime by value of prod(/cons).single. > Or user can call rte_ring_(mp/sp)_enqueue_* functions directly. > This RFC follows exactly the same paradigm: > rte_ring_enqueue(/dequeue)_bulk(/burst) kept generic and it's > behaviour is determined at runtime, by value of prod(/cons).sync_type. > Or user can call enqueue/dequeue with particular sync mode directly: > rte_ring_(mp/sp/rts/hts)_enqueue_(bulk/burst)*. > The only thing that changed: > Format of prod/cons now could differ depending on mode selected at _init_. > So you can't create a ring for let say SP mode and then in the middle of > data-path > change your mind and start using MP_RTS mode. > For existing modes (SP/MP, SC/MC) format remains the same and user can still > use them interchangeably, though of course that is an error prone practice. Makes sense. > > > > But I agree with the problem statement that in the virtualization use > > > case, It may be possible to have N virtual cores runs on a physical > > > core. > > > > > > IMO, The best solution would be keeping the ring API same and have a > > > different flavor in "compile-time". Something like > > > liburcu did for accommodating different flavors. > > > > > > i.e urcu-qsbr.h and urcu-bp.h will identical definition of API. The > > > application can simply include ONE header file in a C file based on > > > the flavor. > > I don't think it is a flexible enough approach. > In one app user might need to have several rings with different sync modes. > Or even user might need a ring with different sync modes for enqueue/dequeue. Ack. > Yes, hiding rte_ring implementation inside .c would help a lot > in terms of ABI maintenance and would make our future life easier. > The question is what is the price for it in terms of performance, > and are we ready to pay it. Not to mention that it would cause > changes in many other libs/apps... > So I think it should be a subject for a separate discussion. > But, agree it would be good at least to measure the performance > impact of such change. > If I'll have some spare cycles, will give it a try. > Meanwhile, can I ask Jerin and other guys to repeat tests from this RFC > on their HW? Before continuing discussion would probably be good to know > does the suggested patch work as expected across different platforms. I tested on an arm64 HW. The former section is without the patch(20.02) and later one with this patch. I agree with Konstantin that getting more platform tests will be good early so that we can focus on the approach to avoid back and forth latter. RTE>>ring_perf_autotest // without path ### Testing single element enq/deq ### legacy APIs: SP/SC: single: 289.78 legacy APIs: MP/MC: single: 516.20 ### Testing burst enq/deq ### legacy APIs: SP/SC: burst (size: 8): 312.88 legacy APIs: SP/SC: burst (size: 32): 426.72 legacy APIs: MP/MC: burst (size: 8): 510.95 legacy APIs: MP/MC: burst (size: 32): 702.01 ### Testing bulk enq/deq ### legacy APIs: SP/SC: bulk (size: 8): 306.74 legacy APIs: SP/SC: bulk (size: 32): 411.56 legacy APIs: MP/MC: bulk (size: 8): 501.32 legacy APIs: MP/MC: bulk (size: 32): 693.07 ### Testing empty bulk deq ### legacy APIs: SP/SC: bulk (size: 8): 7.00 legacy APIs: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### legacy APIs: SP/SC: bulk (size: 8): 74.36 legacy APIs: MP/MC: bulk (size: 8): 110.18 legacy APIs: SP/SC: bulk (size: 32): 23.04 legacy APIs: MP/MC: bulk (size: 32): 32.29 ### Testing using all slave nodes ## Bulk enq/dequeue count on size 8 Core [8] count = 293741 Core [9] count = 293741 Total count (size: 8): 587482 Bulk enq/dequeue count on size 32 Core [8] count = 244909 Core [9] count = 244909 Total count (size: 32): 1077300 ### Testing single element enq/deq ### elem APIs: element size 16B: SP/SC: single: 255.37 elem APIs: element size 16B: MP/MC: single: 456.68 ### Testing burst enq/deq ### elem APIs: element size 16B: SP/SC: burst (size: 8): 291.99 elem APIs: element size 16B: SP/SC: burst (size: 32): 456.25 elem APIs: element size 16B: MP/MC: burst (size: 8): 497.77 elem APIs: element size 16B: MP/MC: burst (size: 32): 680.87 ### Testing bulk enq/deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 284.40 elem APIs: element size 16B: SP/SC: bulk (size: 32): 453.17 elem APIs: element size 16B: MP/MC: bulk (size: 8): 485.77 elem APIs: element size 16B: MP/MC: bulk (size: 32): 675.08 ### Testing empty bulk deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 8.00 elem APIs: element size 16B: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 74.45 elem APIs: element size 16B: MP/MC: bulk (size: 8): 105.91 elem APIs: element
Re: [dpdk-dev] [dpdk-stable] [PATCH] eal: fix log message print for regex
On Thu, Feb 27, 2020 at 9:25 AM Sunil Kumar Kori wrote:
>
> If user passes log-level eal parameter to enable log level based on regex
> then in case of error message is being printed for pattern match instead of
> regex. Following is the warning message thrown:
>
> Compiling C object
> 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_options.c.o'.
> In function ‘eal_parse_log_level’,
>inlined from ‘eal_parse_common_option’ at
> ../lib/librte_eal/common/eal_common_options.c:1418:7:
> ../lib/librte_eal/common/eal_common_options.c:1053:4: warning: ‘%s’ directive
> argument is null [-Wformat-overflow=]
> 1053 |fprintf(stderr, "cannot set log level %s,%d\n",
> |^~~
> 1054 | pattern, priority);
> | ~~
>
Good catch.
Just to understand, how did you catch it?
Extra cflags? specific compiler?
> Fixes: 7f0bb634a140 ("log: add ability to match log type with globbing")
Missing Cc: stable.
>
> Signed-off-by: Sunil Kumar Kori
> ---
> lib/librte_eal/common/eal_common_options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 75974dd5b..525e51e7d 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -1046,7 +1046,7 @@ eal_parse_log_level(const char *arg)
> if (regex) {
> if (rte_log_set_level_regexp(regex, priority) < 0) {
> fprintf(stderr, "cannot set log level %s,%d\n",
> - pattern, priority);
> + regex, priority);
> goto fail;
> }
> if (rte_log_save_regexp(regex, priority) < 0)
> --
> 2.17.1
>
Acked-by: David Marchand
--
David Marchand
[dpdk-dev] [dpdk-announce] DPDK 17.11.10 (LTS) released
Hi all, Here is a new LTS release: https://fast.dpdk.org/rel/dpdk-17.11.10.tar.xz The git tree is at: https://dpdk.org/browse/dpdk-stable/?h=17.11 This is the last point release of the 17.11 LTS series, which is now EOL. Luca Boccassi --- MAINTAINERS| 3 +- app/proc_info/main.c | 36 +-- app/test-crypto-perf/cperf_test_verify.c | 14 +- app/test-pmd/cmdline.c | 7 +- app/test-pmd/config.c | 10 +- app/test-pmd/csumonly.c| 3 + app/test-pmd/parameters.c | 4 +- app/test-pmd/testpmd.c | 7 + app/test-pmd/txonly.c | 2 +- config/common_base | 1 - doc/guides/conf.py | 3 + doc/guides/contributing/coding_style.rst | 8 +- doc/guides/contributing/versioning.rst | 4 +- doc/guides/cryptodevs/aesni_gcm.rst| 3 +- doc/guides/cryptodevs/zuc.rst | 2 +- doc/guides/linux_gsg/nic_perf_intel_platform.rst | 2 +- doc/guides/nics/fm10k.rst | 6 +- doc/guides/nics/liquidio.rst | 4 +- doc/guides/nics/octeontx.rst | 4 +- doc/guides/nics/tap.rst| 6 +- doc/guides/nics/thunderx.rst | 4 +- doc/guides/nics/virtio.rst | 1 - .../generic_segmentation_offload_lib.rst | 2 +- .../prog_guide/packet_classif_access_ctrl.rst | 4 +- doc/guides/prog_guide/rte_security.rst | 4 +- doc/guides/rel_notes/release_17_11.rst | 246 - doc/guides/sample_app_ug/ethtool.rst | 2 +- doc/guides/sample_app_ug/l2_forward_crypto.rst | 2 +- doc/guides/sample_app_ug/performance_thread.rst| 2 +- doc/guides/testpmd_app_ug/testpmd_funcs.rst| 13 +- drivers/bus/fslmc/portal/dpaa2_hw_pvt.h| 2 + drivers/bus/pci/Makefile | 2 +- drivers/bus/pci/linux/pci.c| 13 +- drivers/bus/pci/linux/pci_uio.c| 2 + drivers/bus/pci/linux/pci_vfio.c | 13 +- drivers/crypto/armv8/rte_armv8_pmd.c | 1 - drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c| 2 +- drivers/crypto/mrvl/rte_mrvl_pmd.c | 1 - drivers/crypto/openssl/rte_openssl_pmd.c | 35 ++- drivers/crypto/qat/qat_crypto.c| 6 +- drivers/crypto/qat/qat_crypto_capabilities.h | 4 +- drivers/event/dpaa2/dpaa2_eventdev.c | 5 +- drivers/event/octeontx/Makefile| 1 + drivers/event/octeontx/ssovf_worker.h | 17 +- drivers/event/sw/sw_evdev_xstats.c | 5 +- drivers/mempool/dpaa2/dpaa2_hw_mempool.c | 27 ++- drivers/net/af_packet/rte_eth_af_packet.c | 14 +- drivers/net/bnxt/bnxt.h| 45 drivers/net/bnxt/bnxt_cpr.c| 5 +- drivers/net/bnxt/bnxt_ethdev.c | 133 --- drivers/net/bnxt/bnxt_hwrm.c | 67 +++--- drivers/net/bnxt/bnxt_irq.c| 3 +- drivers/net/bnxt/bnxt_irq.h| 1 + drivers/net/bnxt/bnxt_ring.c | 1 - drivers/net/bnxt/bnxt_rxq.c| 15 +- drivers/net/bnxt/bnxt_rxr.c| 21 +- drivers/net/bnxt/bnxt_stats.c | 35 +++ drivers/net/bnxt/bnxt_txq.c| 3 +- drivers/net/bnxt/bnxt_txr.c| 1 - drivers/net/bonding/rte_eth_bond_8023ad.c | 62 +++--- drivers/net/bonding/rte_eth_bond_args.c| 5 +- drivers/net/bonding/rte_eth_bond_pmd.c | 86 +++ drivers/net/cxgbe/cxgbe_ethdev.c | 9 +- drivers/net/cxgbe/sge.c| 1 - drivers/net/dpaa2/dpaa2_rxtx.c | 51 +++-- drivers/net/dpaa2/mc/dpkg.c| 5 +- drivers/net/e1000/e1000_ethdev.h | 10 +- drivers/net/e1000/igb_ethdev.c | 12 +- drivers/net/e1000/igb_flow.c | 6 + drivers/net/fm10k/base/fm10k_api.c | 20 +- drivers/net/fm10k/base/fm10k_pf.c | 4 +- drivers/net/fm10k/base/fm10k_pf.h | 6 + drivers/net/fm10k/base/fm10k_vf.c | 4 +- drivers/net/fm10k/base/fm10k_vf.h | 5 + drivers/net/fm10k/fm10k_rxtx_vec.c | 11 +- drivers/net/i40e/i40e_ethdev_vf.c | 2 +- drivers/net/i40e/i40e_rxtx_vec_neon.c | 5 +- drivers/
Re: [dpdk-dev] [PATCH] version: 20.05-rc0
On Wed, Feb 26, 2020 at 2:55 PM Thomas Monjalon wrote: > > 26/02/2020 14:38, David Marchand: > > Start a new release cycle with empty release notes. > > ABI must now be checked with v20.02 as a reference. > > > > Signed-off-by: David Marchand > > --- > > .travis.yml| 4 + > > ABI_VERSION| 2 +- > > VERSION| 2 +- > > doc/guides/rel_notes/index.rst | 1 + > > doc/guides/rel_notes/release_20_05.rst | 139 + > > 5 files changed, 146 insertions(+), 2 deletions(-) > > create mode 100644 doc/guides/rel_notes/release_20_05.rst > > Acked-by: Thomas Monjalon Applied, here we go. -- David Marchand
Re: [dpdk-dev] [EXT] Re: [dpdk-stable] [PATCH] eal: fix log message print for regex
Hello David,
We have two build machine with two different version of GCC.
So the issue is reported on one setup only not on the other one.
It looks like because of different version of GCC, this warning is caught.
Regards
Sunil Kumar Kori
>-Original Message-
>From: David Marchand
>Sent: Thursday, February 27, 2020 4:28 PM
>To: Sunil Kumar Kori
>Cc: Olivier Matz ; Thomas Monjalon
>; dev ; dpdk stable
>
>Subject: [EXT] Re: [dpdk-stable] [PATCH] eal: fix log message print for regex
>
>External Email
>
>--
>On Thu, Feb 27, 2020 at 9:25 AM Sunil Kumar Kori
>wrote:
>>
>> If user passes log-level eal parameter to enable log level based on
>> regex then in case of error message is being printed for pattern match
>> instead of regex. Following is the warning message thrown:
>>
>> Compiling C object
>'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_options.c.o'.
>> In function ‘eal_parse_log_level’,
>>inlined from ‘eal_parse_common_option’ at
>../lib/librte_eal/common/eal_common_options.c:1418:7:
>> ../lib/librte_eal/common/eal_common_options.c:1053:4: warning: ‘%s’
>directive argument is null [-Wformat-overflow=]
>> 1053 |fprintf(stderr, "cannot set log level %s,%d\n",
>> |^~~
>> 1054 | pattern, priority);
>> | ~~
>>
>
>Good catch.
>
>Just to understand, how did you catch it?
>Extra cflags? specific compiler?
>
>
>> Fixes: 7f0bb634a140 ("log: add ability to match log type with
>> globbing")
>
>Missing Cc: stable.
>
>
>>
>> Signed-off-by: Sunil Kumar Kori
>> ---
>> lib/librte_eal/common/eal_common_options.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_eal/common/eal_common_options.c
>> b/lib/librte_eal/common/eal_common_options.c
>> index 75974dd5b..525e51e7d 100644
>> --- a/lib/librte_eal/common/eal_common_options.c
>> +++ b/lib/librte_eal/common/eal_common_options.c
>> @@ -1046,7 +1046,7 @@ eal_parse_log_level(const char *arg)
>> if (regex) {
>> if (rte_log_set_level_regexp(regex, priority) < 0) {
>> fprintf(stderr, "cannot set log level %s,%d\n",
>> - pattern, priority);
>> + regex, priority);
>> goto fail;
>> }
>> if (rte_log_save_regexp(regex, priority) < 0)
>> --
>> 2.17.1
>>
>
>Acked-by: David Marchand
>
>
>
>--
>David Marchand
Re: [dpdk-dev] [dpdk-dev PATCH v1 1/1] net/octeontx2: update link information for loopback port
On Thu, Feb 6, 2020 at 5:36 PM Ashish Gupta wrote:
>
> loopback devices are exposed as ethdev device in octeontx2.
> dpdk link update APIs updating the link information for cgx
> ports but skipping loopback ports.
>
> When stack uses loopback port for forwarding, packets are
> dropped as link status is down. Link information need to be
> updated for loopback ports to avoid it.
>
> Fixes: 38f566280a ("net/octeontx2: add link stats operations")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ashish Gupta
Thanks for the patch.
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master after minor rewording of the
commit message. Thanks
> ---
> drivers/net/octeontx2/otx2_link.c | 49
> +--
> 1 file changed, 37 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/octeontx2/otx2_link.c
> b/drivers/net/octeontx2/otx2_link.c
> index f5679b06e..4128f56d9 100644
> --- a/drivers/net/octeontx2/otx2_link.c
> +++ b/drivers/net/octeontx2/otx2_link.c
> @@ -82,32 +82,57 @@ otx2_eth_dev_link_status_update(struct otx2_dev *dev,
> _rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC, NULL);
> }
>
> +static int
> +lbk_link_update(struct rte_eth_link *link)
> +{
> + link->link_status = ETH_LINK_UP;
> + link->link_speed = ETH_SPEED_NUM_100G;
> + link->link_autoneg = ETH_LINK_FIXED;
> + link->link_duplex = ETH_LINK_FULL_DUPLEX;
> + return 0;
> +}
> +
> +static int
> +cgx_link_update(struct otx2_eth_dev *dev, struct rte_eth_link *link)
> +{
> + struct otx2_mbox *mbox = dev->mbox;
> + struct cgx_link_info_msg *rsp;
> + int rc;
> + otx2_mbox_alloc_msg_cgx_get_linkinfo(mbox);
> + rc = otx2_mbox_process_msg(mbox, (void *)&rsp);
> + if (rc)
> + return rc;
> +
> + link->link_status = rsp->link_info.link_up;
> + link->link_speed = rsp->link_info.speed;
> + link->link_autoneg = ETH_LINK_AUTONEG;
> +
> + if (rsp->link_info.full_duplex)
> + link->link_duplex = rsp->link_info.full_duplex;
> + return 0;
> +}
> +
> int
> otx2_nix_link_update(struct rte_eth_dev *eth_dev, int wait_to_complete)
> {
> struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
> - struct otx2_mbox *mbox = dev->mbox;
> - struct cgx_link_info_msg *rsp;
> struct rte_eth_link link;
> int rc;
>
> RTE_SET_USED(wait_to_complete);
> + memset(&link, 0, sizeof(struct rte_eth_link));
>
> - if (otx2_dev_is_lbk(dev) || otx2_dev_is_sdp(dev))
> + if (otx2_dev_is_sdp(dev))
> return 0;
>
> - otx2_mbox_alloc_msg_cgx_get_linkinfo(mbox);
> - rc = otx2_mbox_process_msg(mbox, (void *)&rsp);
> + if (otx2_dev_is_lbk(dev))
> + rc = lbk_link_update(&link);
> + else
> + rc = cgx_link_update(dev, &link);
> +
> if (rc)
> return rc;
>
> - link.link_status = rsp->link_info.link_up;
> - link.link_speed = rsp->link_info.speed;
> - link.link_autoneg = ETH_LINK_AUTONEG;
> -
> - if (rsp->link_info.full_duplex)
> - link.link_duplex = rsp->link_info.full_duplex;
> -
> return rte_eth_linkstatus_set(eth_dev, &link);
> }
>
> --
> 2.14.3
>
Re: [dpdk-dev] [PATCH] version: 20.05-rc0
On Wed, Feb 26, 2020 at 03:01:04PM +0100, David Marchand wrote: > On Wed, Feb 26, 2020 at 2:55 PM Thomas Monjalon wrote: > > > > 26/02/2020 14:38, David Marchand: > > > Start a new release cycle with empty release notes. > > > ABI must now be checked with v20.02 as a reference. > > > > > > Signed-off-by: David Marchand > > > --- > > > .travis.yml| 4 + > > > ABI_VERSION| 2 +- > > > VERSION| 2 +- > > > doc/guides/rel_notes/index.rst | 1 + > > > doc/guides/rel_notes/release_20_05.rst | 139 + > > > 5 files changed, 146 insertions(+), 2 deletions(-) > > > create mode 100644 doc/guides/rel_notes/release_20_05.rst > > > > Acked-by: Thomas Monjalon > > > > > > > --- a/.travis.yml > > > +++ b/.travis.yml > > > +env: > > > + global: > > > +- REF_GIT_TAG=v20.02 > > > > One question: why REF_GIT_TAG was not needed in Travis during 20.02? > > The .ci/linux-build.sh script has a default value for parameters. > http://git.dpdk.org/dpdk/tree/.ci/linux-build.sh#n71&h=v20.02 > > This could be removed, so that we only have explicit values in the > .travis.yml configuration. > No strong opinion keeping them. > Why do we need to update the git ref tag at all. Since these releases are all ABI compatible with each other, can we not leave the checks still to be against 19.11?
Re: [dpdk-dev] [PATCH] version: 20.05-rc0
On Thu, Feb 27, 2020 at 12:17 PM Bruce Richardson wrote: > > On Wed, Feb 26, 2020 at 03:01:04PM +0100, David Marchand wrote: > > On Wed, Feb 26, 2020 at 2:55 PM Thomas Monjalon wrote: > > > > > > 26/02/2020 14:38, David Marchand: > > > > Start a new release cycle with empty release notes. > > > > ABI must now be checked with v20.02 as a reference. > > > > > > > > Signed-off-by: David Marchand > > > > --- > > > > .travis.yml| 4 + > > > > ABI_VERSION| 2 +- > > > > VERSION| 2 +- > > > > doc/guides/rel_notes/index.rst | 1 + > > > > doc/guides/rel_notes/release_20_05.rst | 139 + > > > > 5 files changed, 146 insertions(+), 2 deletions(-) > > > > create mode 100644 doc/guides/rel_notes/release_20_05.rst > > > > > > Acked-by: Thomas Monjalon > > > > > > > > > > --- a/.travis.yml > > > > +++ b/.travis.yml > > > > +env: > > > > + global: > > > > +- REF_GIT_TAG=v20.02 > > > > > > One question: why REF_GIT_TAG was not needed in Travis during 20.02? > > > > The .ci/linux-build.sh script has a default value for parameters. > > http://git.dpdk.org/dpdk/tree/.ci/linux-build.sh#n71&h=v20.02 > > > > This could be removed, so that we only have explicit values in the > > .travis.yml configuration. > > No strong opinion keeping them. > > > Why do we need to update the git ref tag at all. Since these releases are > all ABI compatible with each other, can we not leave the checks still to be > against 19.11? Checking only with 19.11 (major abi) would not detected breakage between minor versions. Like the meter symbols that entered the 20.0.1 version. -- David Marchand
Re: [dpdk-dev] [PATCH] version: 20.05-rc0
27/02/2020 12:23, David Marchand: > On Thu, Feb 27, 2020 at 12:17 PM Bruce Richardson > wrote: > > > > On Wed, Feb 26, 2020 at 03:01:04PM +0100, David Marchand wrote: > > > On Wed, Feb 26, 2020 at 2:55 PM Thomas Monjalon > > > wrote: > > > > > > > > 26/02/2020 14:38, David Marchand: > > > > > Start a new release cycle with empty release notes. > > > > > ABI must now be checked with v20.02 as a reference. > > > > > > > > > > Signed-off-by: David Marchand > > > > > --- > > > > > .travis.yml| 4 + > > > > > ABI_VERSION| 2 +- > > > > > VERSION| 2 +- > > > > > doc/guides/rel_notes/index.rst | 1 + > > > > > doc/guides/rel_notes/release_20_05.rst | 139 > > > > > + > > > > > 5 files changed, 146 insertions(+), 2 deletions(-) > > > > > create mode 100644 doc/guides/rel_notes/release_20_05.rst > > > > > > > > Acked-by: Thomas Monjalon > > > > > > > > > > > > > --- a/.travis.yml > > > > > +++ b/.travis.yml > > > > > +env: > > > > > + global: > > > > > +- REF_GIT_TAG=v20.02 > > > > > > > > One question: why REF_GIT_TAG was not needed in Travis during 20.02? > > > > > > The .ci/linux-build.sh script has a default value for parameters. > > > http://git.dpdk.org/dpdk/tree/.ci/linux-build.sh#n71&h=v20.02 > > > > > > This could be removed, so that we only have explicit values in the > > > .travis.yml configuration. > > > No strong opinion keeping them. > > > > > Why do we need to update the git ref tag at all. Since these releases are > > all ABI compatible with each other, can we not leave the checks still to be > > against 19.11? > > Checking only with 19.11 (major abi) would not detected breakage > between minor versions. > Like the meter symbols that entered the 20.0.1 version. We check that new ABI, introduced in a minor ABI version, is not broken.
Re: [dpdk-dev] [PATCH] version: 20.05-rc0
On Thu, Feb 27, 2020 at 12:01 PM David Marchand wrote: > > On Wed, Feb 26, 2020 at 2:55 PM Thomas Monjalon wrote: > > > > 26/02/2020 14:38, David Marchand: > > > Start a new release cycle with empty release notes. > > > ABI must now be checked with v20.02 as a reference. > > > > > > Signed-off-by: David Marchand > > > --- > > > .travis.yml| 4 + > > > ABI_VERSION| 2 +- > > > VERSION| 2 +- > > > doc/guides/rel_notes/index.rst | 1 + > > > doc/guides/rel_notes/release_20_05.rst | 139 + > > > 5 files changed, 146 insertions(+), 2 deletions(-) > > > create mode 100644 doc/guides/rel_notes/release_20_05.rst > > > > Acked-by: Thomas Monjalon > > Applied, here we go. Patchwork has just been cleaned: old patches archived, Deferred patches back to state NEW. -- David Marchand
Re: [dpdk-dev] [PATCH] net/thunderx: add link up and down ops
On Wed, Feb 5, 2020 at 2:57 PM Harman Kalra wrote:
>
> Add support for .set_link_up/down() eth ops to bring
> link up and down.
>
> Signed-off-by: Harman Kalra
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/net/thunderx/base/nicvf_mbox.c | 10
> drivers/net/thunderx/base/nicvf_mbox.h | 10
> drivers/net/thunderx/nicvf_ethdev.c| 33 ++
> 3 files changed, 53 insertions(+)
>
> diff --git a/drivers/net/thunderx/base/nicvf_mbox.c
> b/drivers/net/thunderx/base/nicvf_mbox.c
> index 8f83d41dd..5b3ab939d 100644
> --- a/drivers/net/thunderx/base/nicvf_mbox.c
> +++ b/drivers/net/thunderx/base/nicvf_mbox.c
> @@ -413,6 +413,16 @@ nicvf_mbox_reset_stat_counters(struct nicvf *nic,
> uint16_t rx_stat_mask,
> return nicvf_mbox_send_msg_to_pf(nic, &mbx);
> }
>
> +int
> +nicvf_mbox_set_link_up_down(struct nicvf *nic, bool enable)
> +{
> + struct nic_mbx mbx = { .msg = { 0 } };
> +
> + mbx.lbk.msg = NIC_MBOX_MSG_SET_LINK;
> + mbx.lbk.vf_id = nic->vf_id;
> + mbx.lbk.enable = enable;
> + return nicvf_mbox_send_msg_to_pf(nic, &mbx);
> +}
> void
> nicvf_mbox_shutdown(struct nicvf *nic)
> {
> diff --git a/drivers/net/thunderx/base/nicvf_mbox.h
> b/drivers/net/thunderx/base/nicvf_mbox.h
> index 81f1f4083..d0b294362 100644
> --- a/drivers/net/thunderx/base/nicvf_mbox.h
> +++ b/drivers/net/thunderx/base/nicvf_mbox.h
> @@ -40,6 +40,7 @@
> #defineNIC_MBOX_MSG_ALLOC_SQS 0x12/* Allocate secondary
> Qset */
> #defineNIC_MBOX_MSG_LOOPBACK 0x16/* Set interface in
> loopback */
> #defineNIC_MBOX_MSG_RESET_STAT_COUNTER 0x17/* Reset statistics
> counters */
> +#defineNIC_MBOX_MSG_SET_LINK 0x21/* Set link up/down */
> #defineNIC_MBOX_MSG_CFG_DONE 0xF0/* VF configuration
> done */
> #defineNIC_MBOX_MSG_SHUTDOWN 0xF1/* VF is being
> shutdown */
> #defineNIC_MBOX_MSG_MAX0x100 /* Maximum number of
> messages */
> @@ -169,6 +170,13 @@ struct reset_stat_cfg {
> uint16_t sq_stat_mask;
> };
>
> +/* Set link up/down */
> +struct set_link_state {
> + uint8_tmsg;
> + uint8_tvf_id;
> + bool enable;
> +};
> +
> struct nic_mbx {
> /* 128 bit shared memory between PF and each VF */
> union {
> @@ -186,6 +194,7 @@ union {
> struct sqs_allocsqs_alloc;
> struct set_loopback lbk;
> struct reset_stat_cfg reset_stat;
> + struct set_link_state set_link;
> };
> };
>
> @@ -210,6 +219,7 @@ int nicvf_mbox_rq_sync(struct nicvf *nic);
> int nicvf_mbox_loopback_config(struct nicvf *nic, bool enable);
> int nicvf_mbox_reset_stat_counters(struct nicvf *nic, uint16_t rx_stat_mask,
> uint8_t tx_stat_mask, uint16_t rq_stat_mask, uint16_t sq_stat_mask);
> +int nicvf_mbox_set_link_up_down(struct nicvf *nic, bool enable);
> void nicvf_mbox_shutdown(struct nicvf *nic);
> void nicvf_mbox_cfg_done(struct nicvf *nic);
>
> diff --git a/drivers/net/thunderx/nicvf_ethdev.c
> b/drivers/net/thunderx/nicvf_ethdev.c
> index 2cf0ffe13..6f43541a5 100644
> --- a/drivers/net/thunderx/nicvf_ethdev.c
> +++ b/drivers/net/thunderx/nicvf_ethdev.c
> @@ -1988,6 +1988,37 @@ nicvf_dev_configure(struct rte_eth_dev *dev)
> return 0;
> }
>
> +static int
> +nicvf_dev_set_link_up(struct rte_eth_dev *dev)
> +{
> + struct nicvf *nic = nicvf_pmd_priv(dev);
> + int rc, i;
> +
> + rc = nicvf_mbox_set_link_up_down(nic, true);
> + if (rc)
> + goto done;
> +
> + /* Start tx queues */
> + for (i = 0; i < dev->data->nb_tx_queues; i++)
> + nicvf_dev_tx_queue_start(dev, i);
> +
> +done:
> + return rc;
> +}
> +
> +static int
> +nicvf_dev_set_link_down(struct rte_eth_dev *dev)
> +{
> + struct nicvf *nic = nicvf_pmd_priv(dev);
> + int i;
> +
> + /* Stop tx queues */
> + for (i = 0; i < dev->data->nb_tx_queues; i++)
> + nicvf_dev_tx_queue_stop(dev, i);
> +
> + return nicvf_mbox_set_link_up_down(nic, false);
> +}
> +
> /* Initialize and register driver with DPDK Application */
> static const struct eth_dev_ops nicvf_eth_dev_ops = {
> .dev_configure= nicvf_dev_configure,
> @@ -2015,6 +2046,8 @@ static const struct eth_dev_ops nicvf_eth_dev_ops = {
> .rx_queue_count = nicvf_dev_rx_queue_count,
> .tx_queue_setup = nicvf_dev_tx_queue_setup,
> .tx_queue_release = nicvf_dev_tx_queue_release,
> + .dev_set_link_up = nicvf_dev_set_link_up,
> + .dev_set_link_down= nicvf_dev_set_link_down,
> .get_reg = nicvf_dev_get_regs,
> };
>
> --
> 2.18.0
>
Re: [dpdk-dev] [EXT] RE: [PATCH v4 12/15] examples/ipsec-secgw: add app mode worker
>
> Hi Lukasz,
>
> > >
> > > Is it not possible to use the existing functions for finding routes,
> > > checking
> > packet types and checking security policies.
> > > It will be very difficult to manage two separate functions for same work.
> > > I
> can
> > see that the pkt->data_offs
> > > Are not required to be updated in the inline case, but can we split the
> > > existing
> > functions in two so that they can be
> > > Called in the appropriate cases.
> > >
> > > As you have said in the cover note as well to add lookaside protocol
> > > support.
> I
> > also tried adding it, and it will get very
> > > Difficult to manage separate functions for separate code paths.
> > >
> >
> > [Lukasz] This was also Konstantin's comment during review of one of previous
> > revisions.
> > The prepare_one_packet() and prepare_tx_pkt() do much more than we need
> > and for performance reasons
> > we crafted new functions. For example, process_ipsec_get_pkt_type function
> > returns nlp and whether
> > packet type is plain or IPsec. That's all. Prepare_one_packet() process
> > packets
> in
> > chunks and does much more -
> > it adjusts mbuf and packet length then it demultiplex packets into plain and
> IPsec
> > flows and finally does
> > inline checks. This is similar for update_mac_addrs() vs prepare_tx_pkt()
> > and
> > check_sp() vs inbound_sp_sa()
> > that prepare_tx_pkt() and inbound_sp_sa() do more that we need in event
> mode.
> >
> > I understand your concern from the perspective of code maintenance but on
> the
> > other hand we are concerned with performance.
> > The current code is not optimized to support multiple mode processing
> > introduced with rte_security. We can work on a common
> > routines once we have other modes also added, so that we can come up with
> a
> > better solution than what we have today.
> >
>
> Yes that is correct, but we should split the existing functions so that the
> part
> which is common
> In both mode should stay common and we do not have duplicate code in the app.
>
> I believe we should take care of this when we add lookaside cases. We shall
> remove all duplicate
> Code. Ideally it should be part of this patchset. But we can postpone it to
> the
> lookaside case addition.
>
>
I believe the route(4/6)_pkts and route(4/6)_pkt can be made uniform quite
easily.
Now you can call either send_single_pkt() or rte_event_eth_tx_adapter_enqueue()
from
the caller of route4_pkts.
I don’t think this will impact the performance at all.
Instead of having 3 for loops, now there will be only 2 and nothing else is
getting changed for
anybody. In fact we can reduce 1 more, if we can call send pkts from inside the
route4_pkts.
I think that can also be done, but it may increase the lookup duration as there
may be cache miss.
But that need to be experimented. What say??
static inline void
route4_pkts(struct rt_ctx *rt_ctx, struct rte_mbuf *pkts[], uint32_t *hop[],
uint8_t nb_pkts)
{
uint32_t dst_ip;
uint16_t i, offset;
if (nb_pkts == 0)
return;
/* Need to do an LPM lookup for non-inline packets. Inline packets will
* have port ID in the SA
*/
for (i = 0; i < nb_pkts; i++) {
if (!(pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD)) {
/* Security offload not enabled. So an LPM lookup is
* required to get the hop
*/
offset = offsetof(struct ip, ip_dst);
dst_ip = *rte_pktmbuf_mtod_offset(pkts[i],
uint32_t *, offset);
dst_ip = rte_be_to_cpu_32(dst_ip);
if (rte_lpm_lookup((struct rte_lpm *)rt_ctx, dst_ip,
hop[i]))
rte_pktmbuf_free(pkts[i]);
} else {
*hop[i] = get_hop_for_offload_pkt(pkts[i], 0);
}
}
}
[dpdk-dev] DPDK Release Status Meeting 27/02/2020
Minutes 27 February 2020 Agenda: * Release Dates * 20.02 Retrospective * Subtrees * OvS Participants: * Arm * Debian/Microsoft * Intel * Marvell * Mellanox * NXP * Red Hat Release Dates - * v20.02 is released on Tuesday, 25 February. * https://mails.dpdk.org/archives/dev/2020-February/158638.html * https://core.dpdk.org/download/ * https://doc.dpdk.org/guides/rel_notes/release_20_02.html * v20.05 dates: * Proposal/V1:Wednesday 18 March 2020 * Integration/Merge/RC1: Friday 17 April 2020 * Release:Wednesday 20 May 2020 * Marvell already sent roadmap for 20.05, all vendors please share the roadmap for the release. 20.02 Retrospective --- * Roadmaps * 20.05 release cycle started and we got only one roadmap Does it help if we get roadmaps 2-3 months early? * Testing delays had a knock on affect in release dates, also affected LTS * It was a small release, we will see if releases will go like this until LTS * 19.02 was small too, we are trending one small one big release cycle * There were ~200 patches deferred, did it contribute being small release? * Some deferred patches was eal and eal doesn't have a maintainer * Pieces under eal has maintainer, 'probing' and 'options' missing maintainer * All library changes hit the main repo, there is a big diversity in patches there * Should we have more sub-trees under main repo, like algo tree, to support the main tree maintenance * This release there were two active main repo maintainer, Thanks David for his work * -rc1 commits / Release commits ratio * It is normally around %60-%70 of all commits pushed in -rc1 * This release it was around %45, so most of the patches merged after -rc1 * This was same in 19.02, both were small releases * Either this was kind of a fix release and lots of issues from past fixed, or we pushed more features after -rc1, need more analysis * More coverity issues fixed in this release * There are still more to address * David will add automated Coverity checks to Travis * Bugzilla issues not actively addressed * Some companies pulling related defects internally and solving them * Release notes is more complete these days, and in better shape, John needs to spend less time to revise it. * It may be good to actively update/fix our documentation * We may need additional resources for it Subtrees * main * next-net * next-net-crypto * next-net-eventdev * next-net-virtio * next-net-intel * LTS * 17.11.10-rc1 released, please test and report results * https://mails.dpdk.org/archives/dev/2020-January/154915.html * QAT issue resolved * Planning to release today, it will be last 17.11 release * 19.11 * Some patches already merged * Request sent to authors for the patches that conflicts * -rc1 planned for next Friday * Release, tentatively, planned for 20 March * 18.11 * Merging patches are progressing OvS --- * 2.13 is out * In OVS-DPDK meeting this Wednesday, there will be rte_flow and HW offload design discussion from Mellanox. Requesting interested parties to attend. * https://mail.openvswitch.org/pipermail/ovs-dev/2020-February/367543.html DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just send an email to "John McNamara " for the invite.
[dpdk-dev] [PATCH v5 0/4] net/virtio: add link speed devarg
[PATCH v5 1/4] net/virtio: refactor devargs parsing [PATCH v5 2/4] net/virtio: add link speed devarg [PATCH v5 3/4] net/virtio-user: fix devargs parsing [PATCH v5 4/4] net/virtio-user: adding link speed devarg --- v5 changes: * fixed code style * fixed commit message and logging text v4 changes: * link_speed renamed to speed devarg * speed devarg is added to virtio-user driver v3 changes: * link_speed devarg is added to virtio documentation
[dpdk-dev] [PATCH v5 1/4] net/virtio: refactor devargs parsing
refactor vdpa specific devargs parsing to more generic way
Signed-off-by: Ivan Dyukov
---
drivers/net/virtio/virtio_ethdev.c | 34 +-
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 044eb10a7..d2c7f8c61 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1955,16 +1955,18 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
}
static int vdpa_check_handler(__rte_unused const char *key,
- const char *value, __rte_unused void *opaque)
+ const char *value, void *ret_val)
{
- if (strcmp(value, "1"))
- return -1;
+ if (strcmp(value, "1") == 0)
+ *(int *)ret_val = 1;
+ else
+ *(int *)ret_val = 0;
return 0;
}
static int
-vdpa_mode_selected(struct rte_devargs *devargs)
+virtio_dev_devargs_parse(struct rte_devargs *devargs, int *vdpa)
{
struct rte_kvargs *kvlist;
const char *key = "vdpa";
@@ -1980,12 +1982,16 @@ vdpa_mode_selected(struct rte_devargs *devargs)
if (!rte_kvargs_count(kvlist, key))
goto exit;
- /* vdpa mode selected when there's a key-value pair: vdpa=1 */
- if (rte_kvargs_process(kvlist, key,
- vdpa_check_handler, NULL) < 0) {
- goto exit;
+ if (vdpa) {
+ /* vdpa mode selected when there's a key-value pair:
+* vdpa=1
+*/
+ ret = rte_kvargs_process(kvlist, key,
+ vdpa_check_handler, vdpa);
+ if (ret < 0)
+ goto exit;
}
- ret = 1;
+
exit:
rte_kvargs_free(kvlist);
@@ -1995,8 +2001,16 @@ vdpa_mode_selected(struct rte_devargs *devargs)
static int eth_virtio_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
struct rte_pci_device *pci_dev)
{
+ int vdpa = 0;
+ int ret = 0;
+
+ ret = virtio_dev_devargs_parse(pci_dev->device.devargs, &vdpa);
+ if (ret < 0) {
+ PMD_INIG_LOG(ERR, "devargs parsing is failed");
+ return ret;
+ }
/* virtio pmd skips probe if device needs to work in vdpa mode */
- if (vdpa_mode_selected(pci_dev->device.devargs))
+ if (vdpa == 1)
return 1;
return rte_eth_dev_pci_generic_probe(pci_dev, sizeof(struct virtio_hw),
--
2.17.1
Re: [dpdk-dev] [PATCH 20.05] net/af_packet: support default mac address change
On 2/15/2020 7:20 PM, Stephen Hemminger wrote: > Since packet is talking to a network device (probably tap) > it is possible for the device driver to change the hardware address > by making an ioctl to kernel. > > Signed-off-by: Stephen Hemminger Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH v5 2/4] net/virtio: add link speed devarg
Some applications like pktgen use link speed to calculate
transmission rate. It limits outcome traffic to hardcoded 10G.
This patch adds speed devarg which allows to configure
link speed of virtio device.
Signed-off-by: Ivan Dyukov
---
doc/guides/nics/virtio.rst | 7 +++
drivers/net/virtio/virtio_ethdev.c | 97 +-
drivers/net/virtio/virtio_pci.h| 1 +
3 files changed, 89 insertions(+), 16 deletions(-)
diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index d1f5fb898..0341907ef 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -356,6 +356,13 @@ Below devargs are supported by the PCI virtio driver:
a virtio device needs to work in vDPA mode.
(Default: 0 (disabled))
+#. ``speed``:
+
+It is used to specify link speed of virtio device. Link speed is a part of
+link status structure. It could be requested by application using
+rte_eth_link_get_nowait function.
+(Default: 1 (10G))
+
Below devargs are supported by the virtio-user vdev:
#. ``path``:
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index d2c7f8c61..1fc1f1139 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -45,6 +45,10 @@ static int virtio_dev_promiscuous_enable(struct rte_eth_dev
*dev);
static int virtio_dev_promiscuous_disable(struct rte_eth_dev *dev);
static int virtio_dev_allmulticast_enable(struct rte_eth_dev *dev);
static int virtio_dev_allmulticast_disable(struct rte_eth_dev *dev);
+static uint32_t virtio_dev_speed_capa_get(uint32_t speed);
+static int virtio_dev_devargs_parse(struct rte_devargs *devargs,
+ int *vdpa,
+ uint32_t *speed);
static int virtio_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int virtio_dev_link_update(struct rte_eth_dev *dev,
@@ -1861,6 +1865,7 @@ int
eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
{
struct virtio_hw *hw = eth_dev->data->dev_private;
+ uint32_t speed = ETH_SPEED_NUM_10G;
int ret;
if (sizeof(struct virtio_net_hdr_mrg_rxbuf) > RTE_PKTMBUF_HEADROOM) {
@@ -1886,7 +1891,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}
-
+ ret = virtio_dev_devargs_parse(eth_dev->device->devargs,
+NULL, &speed);
+ if (ret < 0)
+ return ret;
+ hw->speed = speed;
/*
* Pass the information to the rte_eth_dev_close() that it should also
* release the private port resources.
@@ -1954,6 +1963,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
return 0;
}
+
static int vdpa_check_handler(__rte_unused const char *key,
const char *value, void *ret_val)
{
@@ -1965,33 +1975,89 @@ static int vdpa_check_handler(__rte_unused const char
*key,
return 0;
}
+
+static uint32_t
+virtio_dev_speed_capa_get(uint32_t speed)
+{
+ switch (speed) {
+ case ETH_SPEED_NUM_10G:
+ return ETH_LINK_SPEED_10G;
+ case ETH_SPEED_NUM_20G:
+ return ETH_LINK_SPEED_20G;
+ case ETH_SPEED_NUM_25G:
+ return ETH_LINK_SPEED_25G;
+ case ETH_SPEED_NUM_40G:
+ return ETH_LINK_SPEED_40G;
+ case ETH_SPEED_NUM_50G:
+ return ETH_LINK_SPEED_50G;
+ case ETH_SPEED_NUM_56G:
+ return ETH_LINK_SPEED_56G;
+ case ETH_SPEED_NUM_100G:
+ return ETH_LINK_SPEED_100G;
+ default:
+ return 0;
+ }
+}
+
+
+#define VIRTIO_ARG_SPEED "speed"
+#define VIRTIO_ARG_VDPA "vdpa"
+
+
+static int
+link_speed_handler(const char *key __rte_unused,
+ const char *value, void *ret_val)
+{
+ uint32_t val;
+ if (!value || !ret_val)
+ return -EINVAL;
+ val = strtoul(value, NULL, 0);
+ /* validate input */
+ if (virtio_dev_speed_capa_get(val) == 0)
+ return -EINVAL;
+ *(uint32_t *)ret_val = val;
+
+ return 0;
+}
+
+
static int
-virtio_dev_devargs_parse(struct rte_devargs *devargs, int *vdpa)
+virtio_dev_devargs_parse(struct rte_devargs *devargs, int *vdpa,
+ uint32_t *speed)
{
struct rte_kvargs *kvlist;
- const char *key = "vdpa";
int ret = 0;
if (devargs == NULL)
return 0;
kvlist = rte_kvargs_parse(devargs->args, NULL);
- if (kvlist == NULL)
+ if (kvlist == NULL) {
+ PMD_INIT_LOG(ERR, "error when parsing param");
return 0;
-
- if (!rte_kvargs_count(kvlist, key))
- goto exit;
-
- if (vdpa) {
+ }
+ if (vdpa && rte_kvargs_count(kvlist, VIRTIO_ARG_VDPA) == 1) {
/* vdpa mode selected when there's a key-value pair:
* vdpa=1
*/
- ret = rte_kvargs_process(kvlist, key,
+
[dpdk-dev] [PATCH v5 4/4] net/virtio-user: adding link speed devarg
virtio driver already parses speed devarg. virtio-user should add
it to list of valid devargs and call eth_virtio_dev_init function
which init speed value.
eth_virtio_dev_init already is called from virtio_user_pmd_probe
function. The only change is required to enable speed devargs:
adding speed to list of valid devargs.
Signed-off-by: Ivan Dyukov
---
doc/guides/nics/virtio.rst | 8
drivers/net/virtio/virtio_user_ethdev.c | 5 -
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 0341907ef..6286286db 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -410,6 +410,14 @@ Below devargs are supported by the virtio-user vdev:
It is used to enable virtio device packed virtqueue feature.
(Default: 0 (disabled))
+#. ``speed``:
+
+It is used to specify link speed of virtio device. Link speed is a part of
+link status structure. It could be requested by application using
+rte_eth_link_get_nowait function.
+(Default: 1 (10G))
+
+
Virtio paths Selection and Usage
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 074527714..45c1541c5 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -406,6 +406,8 @@ static const char *valid_args[] = {
VIRTIO_USER_ARG_IN_ORDER,
#define VIRTIO_USER_ARG_PACKED_VQ "packed_vq"
VIRTIO_USER_ARG_PACKED_VQ,
+#define VIRTIO_USER_ARG_SPEED "speed"
+ VIRTIO_USER_ARG_SPEED,
NULL
};
@@ -738,4 +740,5 @@ RTE_PMD_REGISTER_PARAM_STRING(net_virtio_user,
"server=<0|1> "
"mrg_rxbuf=<0|1> "
"in_order=<0|1> "
- "packed_vq=<0|1>");
+ "packed_vq=<0|1> "
+ "speed=");
--
2.17.1
[dpdk-dev] [PATCH v5 3/4] net/virtio-user: fix devargs parsing
strtoull returns 0 if it fails to parse input string. It's ignored
in get_integer_arg.
This patch handles error cases for strtoull function.
Signed-off-by: Ivan Dyukov
---
drivers/net/virtio/virtio_user_ethdev.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 3fc172573..074527714 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -433,12 +433,17 @@ static int
get_integer_arg(const char *key __rte_unused,
const char *value, void *extra_args)
{
+ uint64_t integer = 0;
if (!value || !extra_args)
return -EINVAL;
-
- *(uint64_t *)extra_args = strtoull(value, NULL, 0);
-
- return 0;
+ errno = 0;
+ integer = strtoull(value, NULL, 0);
+ /* extra_args keeps default value, it should be replaced
+* only in case of successful parsing of the 'value' arg
+*/
+ if (errno == 0)
+ *(uint64_t *)extra_args = integer;
+ return -errno;
}
static struct rte_eth_dev *
--
2.17.1
Re: [dpdk-dev] [PATCH v1] net/axgbe: add support for Scattered Rx
On 2/27/2020 6:33 AM, sseba...@amd.com wrote: > From: Selwin Sebastian > > Enable scattered rx support and add jumbo packet transmit capability > > Signed-off-by: Selwin Sebastian <...> > @@ -789,11 +789,17 @@ axgbe_dev_info_get(struct rte_eth_dev *dev, struct > rte_eth_dev_info *dev_info) > DEV_RX_OFFLOAD_IPV4_CKSUM | > DEV_RX_OFFLOAD_UDP_CKSUM | > DEV_RX_OFFLOAD_TCP_CKSUM | > + DEV_RX_OFFLOAD_JUMBO_FRAME | > + DEV_RX_OFFLOAD_SCATTER| > DEV_RX_OFFLOAD_KEEP_CRC; > > dev_info->tx_offload_capa = > DEV_TX_OFFLOAD_IPV4_CKSUM | > DEV_TX_OFFLOAD_UDP_CKSUM | > + DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | > + DEV_TX_OFFLOAD_UDP_TSO | > + DEV_TX_OFFLOAD_SCTP_CKSUM | > + DEV_TX_OFFLOAD_MULTI_SEGS | > DEV_TX_OFFLOAD_TCP_CKSUM; Is the Tx offload capability update related to the this change? If it is not can you please send these updates as a separate patch, and a send new version of this patch without this bit? Thanks, ferruh
Re: [dpdk-dev] [EXT] RE: [PATCH v4 12/15] examples/ipsec-secgw: add app mode worker
Hi Akhil,
Please see my answer below.
Thanks,
Lukasz
On 27.02.2020 13:07, Akhil Goyal wrote:
>>
>> Hi Lukasz,
>>
Is it not possible to use the existing functions for finding routes,
checking
>>> packet types and checking security policies.
It will be very difficult to manage two separate functions for same work. I
>> can
>>> see that the pkt->data_offs
Are not required to be updated in the inline case, but can we split the
existing
>>> functions in two so that they can be
Called in the appropriate cases.
As you have said in the cover note as well to add lookaside protocol
support.
>> I
>>> also tried adding it, and it will get very
Difficult to manage separate functions for separate code paths.
>>>
>>> [Lukasz] This was also Konstantin's comment during review of one of previous
>>> revisions.
>>> The prepare_one_packet() and prepare_tx_pkt() do much more than we need
>>> and for performance reasons
>>> we crafted new functions. For example, process_ipsec_get_pkt_type function
>>> returns nlp and whether
>>> packet type is plain or IPsec. That's all. Prepare_one_packet() process
>>> packets
>> in
>>> chunks and does much more -
>>> it adjusts mbuf and packet length then it demultiplex packets into plain and
>> IPsec
>>> flows and finally does
>>> inline checks. This is similar for update_mac_addrs() vs prepare_tx_pkt()
>>> and
>>> check_sp() vs inbound_sp_sa()
>>> that prepare_tx_pkt() and inbound_sp_sa() do more that we need in event
>> mode.
>>>
>>> I understand your concern from the perspective of code maintenance but on
>> the
>>> other hand we are concerned with performance.
>>> The current code is not optimized to support multiple mode processing
>>> introduced with rte_security. We can work on a common
>>> routines once we have other modes also added, so that we can come up with
>> a
>>> better solution than what we have today.
>>>
>>
>> Yes that is correct, but we should split the existing functions so that the
>> part
>> which is common
>> In both mode should stay common and we do not have duplicate code in the app.
>>
>> I believe we should take care of this when we add lookaside cases. We shall
>> remove all duplicate
>> Code. Ideally it should be part of this patchset. But we can postpone it to
>> the
>> lookaside case addition.
>>
>>
>
> I believe the route(4/6)_pkts and route(4/6)_pkt can be made uniform quite
> easily.
> Now you can call either send_single_pkt() or
> rte_event_eth_tx_adapter_enqueue() from
> the caller of route4_pkts.
> I don’t think this will impact the performance at all.
> Instead of having 3 for loops, now there will be only 2 and nothing else is
> getting changed for
> anybody. In fact we can reduce 1 more, if we can call send pkts from inside
> the route4_pkts.
> I think that can also be done, but it may increase the lookup duration as
> there may be cache miss.
> But that need to be experimented. What say??
>
> static inline void
> route4_pkts(struct rt_ctx *rt_ctx, struct rte_mbuf *pkts[], uint32_t *hop[],
> uint8_t nb_pkts)
> {
> uint32_t dst_ip;
> uint16_t i, offset;
>
> if (nb_pkts == 0)
> return;
>
> /* Need to do an LPM lookup for non-inline packets. Inline packets
> will
> * have port ID in the SA
> */
>
> for (i = 0; i < nb_pkts; i++) {
> if (!(pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD)) {
> /* Security offload not enabled. So an LPM lookup is
> * required to get the hop
> */
> offset = offsetof(struct ip, ip_dst);
> dst_ip = *rte_pktmbuf_mtod_offset(pkts[i],
> uint32_t *, offset);
> dst_ip = rte_be_to_cpu_32(dst_ip);
> if (rte_lpm_lookup((struct rte_lpm *)rt_ctx, dst_ip,
> hop[i]))
> rte_pktmbuf_free(pkts[i]);
> } else {
> *hop[i] = get_hop_for_offload_pkt(pkts[i], 0);
> }
> }
> }
>
[Lukasz] Thank you for your suggestion. Looking at the proposed change I have
major concern related
to performance. Current rout4_pkts uses rte_lpm_lookup_bulk() which can benefit
from SIMD instructions.
Replacing it with rte_lpm_lookup might introduce substantial performance
degradation. I will start
experimenting with processing functions (routing packets, checking packet type,
checking sp policies) to make
them as much common as possible between poll and event modes. As agreed the
plan is to make processing functions common
with the addition of lookaside event mode. In the meantime I will send V5 event
mode patches which address your other comments.
Re: [dpdk-dev] [PATCH v1] net/axgbe: add support for Scattered Rx
[AMD Official Use Only - Internal Distribution Only] Hi Ferruh, For validation of scatter using the testpmd method mentioned in dpdk docs, we need to have these Tx offloads also enabled. Thanks and Regards Selwin Sebastian -Original Message- From: Ferruh Yigit Sent: Thursday, February 27, 2020 7:59 PM To: Sebastian, Selwin ; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v1] net/axgbe: add support for Scattered Rx [CAUTION: External Email] On 2/27/2020 6:33 AM, sseba...@amd.com wrote: > From: Selwin Sebastian > > Enable scattered rx support and add jumbo packet transmit capability > > Signed-off-by: Selwin Sebastian <...> > @@ -789,11 +789,17 @@ axgbe_dev_info_get(struct rte_eth_dev *dev, struct > rte_eth_dev_info *dev_info) > DEV_RX_OFFLOAD_IPV4_CKSUM | > DEV_RX_OFFLOAD_UDP_CKSUM | > DEV_RX_OFFLOAD_TCP_CKSUM | > + DEV_RX_OFFLOAD_JUMBO_FRAME | > + DEV_RX_OFFLOAD_SCATTER| > DEV_RX_OFFLOAD_KEEP_CRC; > > dev_info->tx_offload_capa = > DEV_TX_OFFLOAD_IPV4_CKSUM | > DEV_TX_OFFLOAD_UDP_CKSUM | > + DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | > + DEV_TX_OFFLOAD_UDP_TSO | > + DEV_TX_OFFLOAD_SCTP_CKSUM | > + DEV_TX_OFFLOAD_MULTI_SEGS | > DEV_TX_OFFLOAD_TCP_CKSUM; Is the Tx offload capability update related to the this change? If it is not can you please send these updates as a separate patch, and a send new version of this patch without this bit? Thanks, ferruh
Re: [dpdk-dev] [PATCH v1] net/axgbe: add support for Scattered Rx
On 2/27/2020 2:35 PM, Sebastian, Selwin wrote: > [AMD Official Use Only - Internal Distribution Only] > > Hi Ferruh, > For validation of scatter using the testpmd method mentioned in dpdk > docs, we need to have these Tx offloads also enabled. [Please don't top post, it makes conversation hard to follow.] Can you point where there testpmd requirement in the code? Also these offloads should be enabled when HW/Driver supports it, not for it is required by testpmd. > > Thanks and Regards > Selwin Sebastian > > -Original Message- > From: Ferruh Yigit > Sent: Thursday, February 27, 2020 7:59 PM > To: Sebastian, Selwin ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1] net/axgbe: add support for Scattered Rx > > [CAUTION: External Email] > > On 2/27/2020 6:33 AM, sseba...@amd.com wrote: >> From: Selwin Sebastian >> >> Enable scattered rx support and add jumbo packet transmit capability >> >> Signed-off-by: Selwin Sebastian > > <...> > >> @@ -789,11 +789,17 @@ axgbe_dev_info_get(struct rte_eth_dev *dev, struct >> rte_eth_dev_info *dev_info) >> DEV_RX_OFFLOAD_IPV4_CKSUM | >> DEV_RX_OFFLOAD_UDP_CKSUM | >> DEV_RX_OFFLOAD_TCP_CKSUM | >> + DEV_RX_OFFLOAD_JUMBO_FRAME | >> + DEV_RX_OFFLOAD_SCATTER| >> DEV_RX_OFFLOAD_KEEP_CRC; >> >> dev_info->tx_offload_capa = >> DEV_TX_OFFLOAD_IPV4_CKSUM | >> DEV_TX_OFFLOAD_UDP_CKSUM | >> + DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | >> + DEV_TX_OFFLOAD_UDP_TSO | >> + DEV_TX_OFFLOAD_SCTP_CKSUM | >> + DEV_TX_OFFLOAD_MULTI_SEGS | >> DEV_TX_OFFLOAD_TCP_CKSUM; > > Is the Tx offload capability update related to the this change? If it is not > can you please send these updates as a separate patch, and a send new version > of this patch without this bit? > > Thanks, > ferruh >
[dpdk-dev] [RFC v4] regexdev: introduce regexdev subsystem
From: Jerin Jacob Even though there are some vendors which offer Regex HW offload, due to lack of standard API, It is diffcult for DPDK consumer to use them in a portable way. This _RFC_ attempts to standardize the RegEx/DPI offload APIs for DPDK. This RFC crafted based on SW Regex API frameworks such as libpcre and hyperscan and a few of the RegEx HW IPs which I am aware of. RegEx pattern matching applications: * Next Generation Firewalls (NGFW) * Deep Packet and Flow Inspection (DPI) * Intrusion Prevention Systems (IPS) * DDoS Mitigation * Network Monitoring * Data Loss Prevention (DLP) * Smart NICs * Grammar based content processing * URL, spam and adware filtering * Advanced auditing and policing of user/application security policies * Financial data mining - parsing of streamed financial feeds * Application recognition. * Dmemory introspection. * Natural Language Processing (NLP) * Sentiment Analysis. * Big data databse acceleration. * Computational storage. Request to review from HW and SW RegEx vendors and RegEx application users to have portable DPDK API for RegEx. The API schematics are based cryptodev, eventdev and ethdev existing device API. Signed-off-by: Jerin Jacob Signed-off-by: Pavan Nikhilesh Signed-off-by: Ori Kam --- V4: * Replace iova with mbuf. * Small ML comments. V3: * Change subject title. V2: * Address ML comments. --- config/common_base |7 + doc/api/doxy-api-index.md|1 + doc/api/doxy-api.conf.in |1 + lib/Makefile |2 + lib/librte_regexdev/Makefile | 31 + lib/librte_regexdev/rte_regexdev.c |6 + lib/librte_regexdev/rte_regexdev.h | 1393 ++ lib/librte_regexdev/rte_regexdev_version.map | 26 + 8 files changed, 1467 insertions(+) create mode 100644 lib/librte_regexdev/Makefile create mode 100644 lib/librte_regexdev/rte_regexdev.c create mode 100644 lib/librte_regexdev/rte_regexdev.h create mode 100644 lib/librte_regexdev/rte_regexdev_version.map diff --git a/config/common_base b/config/common_base index f9a68f3..4810849 100644 --- a/config/common_base +++ b/config/common_base @@ -806,6 +806,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV=y CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y # +# Compile regex device support +# +CONFIG_RTE_LIBRTE_REGEXDEV=y +CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n + +# # Compile librte_ring # CONFIG_RTE_LIBRTE_RING=y @@ -1098,3 +1104,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y # Compile the eventdev application # CONFIG_RTE_APP_EVENTDEV=y + diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index dff496b..787f7c2 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -26,6 +26,7 @@ The public API headers are grouped by topics: [event_timer_adapter](@ref rte_event_timer_adapter.h), [event_crypto_adapter] (@ref rte_event_crypto_adapter.h), [rawdev] (@ref rte_rawdev.h), + [regexdev] (@ref rte_regexdev.h), [metrics](@ref rte_metrics.h), [bitrate](@ref rte_bitrate.h), [latency](@ref rte_latencystats.h), diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in index 1c4392e..56c08eb 100644 --- a/doc/api/doxy-api.conf.in +++ b/doc/api/doxy-api.conf.in @@ -58,6 +58,7 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \ @TOPDIR@/lib/librte_rcu \ @TOPDIR@/lib/librte_reorder \ @TOPDIR@/lib/librte_rib \ + @TOPDIR@/lib/librte_regexdev \ @TOPDIR@/lib/librte_ring \ @TOPDIR@/lib/librte_sched \ @TOPDIR@/lib/librte_security \ diff --git a/lib/Makefile b/lib/Makefile index 46b91ae..a273564 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \ librte_mempool librte_timer librte_cryptodev DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev DEPDIRS-librte_rawdev := librte_eal librte_ethdev +DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev +DEPDIRS-librte_regexdev := librte_eal librte_mbuf DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \ librte_net librte_hash librte_cryptodev diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile new file mode 100644 index 000..6f4cc63 --- /dev/null +++ b/lib/librte_regexdev/Makefile @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(C) 2019 Marvell International Ltd. +# Copyright(C) 2020 Mellanox International Ltd. +# + +include $(RTE_SDK)/mk/rte.vars.mk + +# library name +LIB = librte_regexdev.a + +EXPORT_MAP := rte_regex_version.map + +# library version +LIBABIVER := 1 + +#
Re: [dpdk-dev] [RFC v4] regexdev: introduce regexdev subsystem
On Thu, Feb 27, 2020 at 8:11 PM Ori Kam wrote:
>
> From: Jerin Jacob
>
> Even though there are some vendors which offer Regex HW offload, due to
> lack of standard API, It is diffcult for DPDK consumer to use them
> in a portable way.
>
> This _RFC_ attempts to standardize the RegEx/DPI offload APIs for DPDK.
>
> This RFC crafted based on SW Regex API frameworks such as libpcre and
> hyperscan and a few of the RegEx HW IPs which I am aware of.
>
> RegEx pattern matching applications:
> * Next Generation Firewalls (NGFW)
> * Deep Packet and Flow Inspection (DPI)
> * Intrusion Prevention Systems (IPS)
> * DDoS Mitigation
> * Network Monitoring
> * Data Loss Prevention (DLP)
> * Smart NICs
> * Grammar based content processing
> * URL, spam and adware filtering
> * Advanced auditing and policing of user/application security policies
> * Financial data mining - parsing of streamed financial feeds
> * Application recognition.
> * Dmemory introspection.
> * Natural Language Processing (NLP)
> * Sentiment Analysis.
> * Big data databse acceleration.
> * Computational storage.
>
> Request to review from HW and SW RegEx vendors and RegEx application
> users to have portable DPDK API for RegEx.
>
> The API schematics are based cryptodev, eventdev and ethdev existing
> device API.
>
> Signed-off-by: Jerin Jacob
> Signed-off-by: Pavan Nikhilesh
> Signed-off-by: Ori Kam
> ---
> V4:
> * Replace iova with mbuf.
> * Small ML comments.
> V3:
> * Change subject title.
> V2:
> * Address ML comments.
> +/** Struct to hold scatter gather elements in ops. */
> +struct rte_regex_iov {
> + RTE_STD_C11
> + union {
> + uint64_t u64;
> + /**< Allow 8-byte reserved on 32-bit system */
> + void *buf_addr;
> + /**< Virtual address of the pattern to be matched. */
> + };
> + rte_iova_t buf_iova;
> + /**< IOVA address of the pattern to be matched. */
> + uint16_t buf_size; /**< The buf size. */
> +};
rte_regex_iov structure is stale . Please remove it.
[dpdk-dev] [Bug 413] rte_ring: capacity was set uncorrectly
https://bugs.dpdk.org/show_bug.cgi?id=413 Bug ID: 413 Summary: rte_ring: capacity was set uncorrectly Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: 781345...@qq.com Target Milestone: --- In function `rte_ring_init()` in `lib/librte_ring/rte_ring.c`, `capacity` was set to `mask` when count was power of 2, while `mask` was set to `count - 1`. But when specified with flag `RING_F_EXACT_SZ`, `capacity` was set to `count`. I think `capacity` should be set to `count` anyway. It's illogical when you create a ring of count 4096 but you can only use 4095 of it. And when you create a ring of count 4095, you can use 4095 of it. Their logic should be identical. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [RFC v5] regexdev: introduce regexdev subsystem
From: Jerin Jacob Even though there are some vendors which offer Regex HW offload, due to lack of standard API, It is diffcult for DPDK consumer to use them in a portable way. This _RFC_ attempts to standardize the RegEx/DPI offload APIs for DPDK. This RFC crafted based on SW Regex API frameworks such as libpcre and hyperscan and a few of the RegEx HW IPs which I am aware of. RegEx pattern matching applications: * Next Generation Firewalls (NGFW) * Deep Packet and Flow Inspection (DPI) * Intrusion Prevention Systems (IPS) * DDoS Mitigation * Network Monitoring * Data Loss Prevention (DLP) * Smart NICs * Grammar based content processing * URL, spam and adware filtering * Advanced auditing and policing of user/application security policies * Financial data mining - parsing of streamed financial feeds * Application recognition. * Dmemory introspection. * Natural Language Processing (NLP) * Sentiment Analysis. * Big data databse acceleration. * Computational storage. Request to review from HW and SW RegEx vendors and RegEx application users to have portable DPDK API for RegEx. The API schematics are based cryptodev, eventdev and ethdev existing device API. Signed-off-by: Jerin Jacob Signed-off-by: Pavan Nikhilesh Signed-off-by: Ori Kam --- V5: * Remove unused iov struct. V4: * Replace iov with mbuf. * Small ML comments. V3: * Change subject title. V2: * Address ML comments. --- config/common_base |7 + doc/api/doxy-api-index.md|1 + doc/api/doxy-api.conf.in |1 + lib/Makefile |2 + lib/librte_regexdev/Makefile | 31 + lib/librte_regexdev/rte_regexdev.c |6 + lib/librte_regexdev/rte_regexdev.h | 1379 ++ lib/librte_regexdev/rte_regexdev_version.map | 26 + 8 files changed, 1453 insertions(+) create mode 100644 lib/librte_regexdev/Makefile create mode 100644 lib/librte_regexdev/rte_regexdev.c create mode 100644 lib/librte_regexdev/rte_regexdev.h create mode 100644 lib/librte_regexdev/rte_regexdev_version.map diff --git a/config/common_base b/config/common_base index f9a68f3..4810849 100644 --- a/config/common_base +++ b/config/common_base @@ -806,6 +806,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV=y CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y # +# Compile regex device support +# +CONFIG_RTE_LIBRTE_REGEXDEV=y +CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n + +# # Compile librte_ring # CONFIG_RTE_LIBRTE_RING=y @@ -1098,3 +1104,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y # Compile the eventdev application # CONFIG_RTE_APP_EVENTDEV=y + diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index dff496b..787f7c2 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -26,6 +26,7 @@ The public API headers are grouped by topics: [event_timer_adapter](@ref rte_event_timer_adapter.h), [event_crypto_adapter] (@ref rte_event_crypto_adapter.h), [rawdev] (@ref rte_rawdev.h), + [regexdev] (@ref rte_regexdev.h), [metrics](@ref rte_metrics.h), [bitrate](@ref rte_bitrate.h), [latency](@ref rte_latencystats.h), diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in index 1c4392e..56c08eb 100644 --- a/doc/api/doxy-api.conf.in +++ b/doc/api/doxy-api.conf.in @@ -58,6 +58,7 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \ @TOPDIR@/lib/librte_rcu \ @TOPDIR@/lib/librte_reorder \ @TOPDIR@/lib/librte_rib \ + @TOPDIR@/lib/librte_regexdev \ @TOPDIR@/lib/librte_ring \ @TOPDIR@/lib/librte_sched \ @TOPDIR@/lib/librte_security \ diff --git a/lib/Makefile b/lib/Makefile index 46b91ae..a273564 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \ librte_mempool librte_timer librte_cryptodev DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev DEPDIRS-librte_rawdev := librte_eal librte_ethdev +DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev +DEPDIRS-librte_regexdev := librte_eal librte_mbuf DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \ librte_net librte_hash librte_cryptodev diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile new file mode 100644 index 000..6f4cc63 --- /dev/null +++ b/lib/librte_regexdev/Makefile @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(C) 2019 Marvell International Ltd. +# Copyright(C) 2020 Mellanox International Ltd. +# + +include $(RTE_SDK)/mk/rte.vars.mk + +# library name +LIB = librte_regexdev.a + +EXPORT_MAP := rte_regex_version.map + +# libr
Re: [dpdk-dev] Windows Draft Build
> 3. Patch instruction is a bit involved: > > * Base on windpdk-v18.08-clang. > * Import drivers/net/virtio from v18.08 (not attached due to size). > * Apply windpdk-virtio-1.patch (attached). > * Apply multi-BAR patches (not attached due to not being mine). > * Apply windpdk-virtio-2.patch (attached). Hi Dmitry, I did not see any attachment of the above. Can you send again? Thanks William > > There is one patch in windpdk-virtio-2.patch that splits PCI config I/O of > arbitrary size to a series of 4/2/1 accesses. It is implemented in user-mode > because it was easier to debug, but maybe it should be moved to netUIO, so > that any region of PCI config space can be read/written in a single syscall. > > -- > Dmitry Kozlyuk
Re: [dpdk-dev] Windows Draft Build
On Thu, Feb 27, 2020 at 4:27 PM William Tu wrote: > > > 3. Patch instruction is a bit involved: > > > > * Base on windpdk-v18.08-clang. > > * Import drivers/net/virtio from v18.08 (not attached due to size). > > * Apply windpdk-virtio-1.patch (attached). > > * Apply multi-BAR patches (not attached due to not being mine). > > * Apply windpdk-virtio-2.patch (attached). > > Hi Dmitry, > I did not see any attachment of the above. > Can you send again? Attachments are dropped on the dev@ mailing list. So please send the patches as you would do for a normal proposal, adding a RFC prefix if you prefer to tag them. -- David Marchand
[dpdk-dev] net/netvsc: subchannel configuration failed due to unexpected NVS response
Hi Stephen:
I saw the following error messages when using DPDK 18.11.2 in Azure:
hn_nvs_execute(): unexpected NVS resp 0x6b, expect 0x85
hn_dev_configure(): subchannel configuration failed
It was not easy to reproduce it and it only occurred with multiple queues
enabled. In hn_nvs_execute it expects the response to match the request. In
the failed case, it was expecting NVS_TYPE_SUBCH_REQ (133 or 0x85) but
got NVS_TYPE_RNDIS(107 or 0x6b). Obviously somewhere the NVS_TYPE_RNDIS
message had been sent before the NVS_TYPE_SUBCH_REQ message was sent. I
looked at the code and found that the NVS_TYPE_RNDIS message needs
completion response but it does not receive the response message anywhere.
The fix would be receiving and discarding the wrong response message(s).
I put the following patches and it has fixed the problem.
--- a/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:08:29.755530969 -0500
+++ b/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:07:21.567371798 -0500
@@ -92,7 +92,7 @@
if (hdr->type != type) {
PMD_DRV_LOG(ERR, "unexpected NVS resp %#x, expect %#x",
hdr->type, type);
- goto retry;
+ return -EINVAL;
}
if (len < resplen) {
[dpdk-dev] [PATCH v5 00/15] add eventmode to ipsec-secgw
This series introduces event-mode additions to ipsec-secgw. With this series, ipsec-secgw would be able to run in eventmode. The worker thread (executing loop) would be receiving events and would be submitting it back to the eventdev after the processing. This way, multicore scaling and h/w assisted scheduling is achieved by making use of the eventdev capabilities. Since the underlying event device would be having varying capabilities, the worker thread could be drafted differently to maximize performance. This series introduces usage of multiple worker threads, among which the one to be used will be determined by the operating conditions and the underlying device capabilities. For example, if an event device - eth device pair has Tx internal port, then application can do tx_adapter_enqueue() instead of regular event_enqueue(). So a thread making an assumption that the device pair has internal port will not be the right solution for another pair. The infrastructure added with these patches aims to help application to have multiple worker threads, there by extracting maximum performance from every device without affecting existing paths/use cases. The eventmode configuration is predefined. All packets reaching one eth port will hit one event queue. All event queues will be mapped to all event ports. So all cores will be able to receive traffic from all ports. When schedule_type is set as RTE_SCHED_TYPE_ORDERED/ATOMIC, event device will ensure the ordering. Ordering would be lost when tried in PARALLEL. Following command line options are introduced, --transfer-mode: to choose between poll mode & event mode --event-schedule-type: to specify the scheduling type (RTE_SCHED_TYPE_ORDERED/ RTE_SCHED_TYPE_ATOMIC/ RTE_SCHED_TYPE_PARALLEL) Additionally the event mode introduces two modes of processing packets: Driver-mode: This mode will have bare minimum changes in the application to support ipsec. There woudn't be any lookup etc done in the application. And for inline-protocol use case, the thread would resemble l2fwd as the ipsec processing would be done entirely in the h/w. This mode can be used to benchmark the raw performance of the h/w. All the application side steps (like lookup) can be redone based on the requirement of the end user. Hence the need for a mode which would report the raw performance. App-mode: This mode will have all the features currently implemented with ipsec-secgw (non librte_ipsec mode). All the lookups etc would follow the existing methods and would report numbers that can be compared against regular ipsec-secgw benchmark numbers. The driver mode is selected with existing --single-sa option (used also by poll mode). When --single-sa option is used in conjution with event mode then index passed to --single-sa is ignored. Example commands to execute ipsec-secgw in various modes on OCTEON TX2 platform, #Inbound and outbound app mode ipsec-secgw -w 0002:02:00.0,ipsec_in_max_spi=128 -w 0002:03:00.0,ipsec_in_max_spi=128 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x1 -- -P -p 0x3 -u 0x1 -f aes-gcm.cfg --transfer-mode event --event-schedule-type parallel #Inbound and outbound driver mode ipsec-secgw -w 0002:02:00.0,ipsec_in_max_spi=128 -w 0002:03:00.0,ipsec_in_max_spi=128 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x1 -- -P -p 0x3 -u 0x1 -f aes-gcm.cfg --transfer-mode event --event-schedule-type parallel --single-sa 0 This series adds non burst tx internal port workers only. It provides infrastructure for non internal port workers, however does not define any. Also, only inline ipsec protocol mode is supported by the worker threads added. Following are planned features, 1. Add burst mode workers. 2. Add non internal port workers. 3. Verify support for Rx core (the support is added but lack of h/w to verify). 4. Add lookaside protocol support. Following are features that Marvell won't be attempting. 1. Inline crypto support. 2. Lookaside crypto support. For the features that Marvell won't be attempting, new workers can be introduced by the respective stake holders. This series is tested on Marvell OCTEON TX2. This series is targeted for 20.05 release. Changes in v5: * Rename function check_params() to check_poll_mode_params() and check_eh_conf() to check_event_mode_params() in order to make it clear what is their purpose. * Forbid usage of --config option in event mode. * Replace magic numbers on return with enum values in process_ipsec_ev_inbound() and process_ipsec_ev_outbound() functions. * Add session_priv_pool for both inbound and outbound configuration in ipsec_wrkr_non_burst_int_port_app_mode worker. * Add check of event type in ipsec_wrkr_non_burst_int_port_app_mode worker. * Update description of --config option in both ipsec-secgw help and docum
[dpdk-dev] [PATCH v5 02/15] examples/ipsec-secgw: add framework for eventmode helper
From: Anoob Joseph
Add framework for eventmode helper. Event mode involves
initialization of multiple devices like eventdev, ethdev
and etc. Add routines to initialize and uninitialize event
device. Generate a default config for event device if it
is not specified in the configuration. Currently event
helper supports single event device only.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/Makefile | 1 +
examples/ipsec-secgw/event_helper.c | 320
examples/ipsec-secgw/event_helper.h | 107
examples/ipsec-secgw/meson.build| 4 +-
4 files changed, 430 insertions(+), 2 deletions(-)
create mode 100644 examples/ipsec-secgw/event_helper.c
create mode 100644 examples/ipsec-secgw/event_helper.h
diff --git a/examples/ipsec-secgw/Makefile b/examples/ipsec-secgw/Makefile
index ad83d79..66d05d4 100644
--- a/examples/ipsec-secgw/Makefile
+++ b/examples/ipsec-secgw/Makefile
@@ -16,6 +16,7 @@ SRCS-y += sad.c
SRCS-y += rt.c
SRCS-y += ipsec_process.c
SRCS-y += ipsec-secgw.c
+SRCS-y += event_helper.c
CFLAGS += -gdwarf-2
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
new file mode 100644
index 000..0c38474
--- /dev/null
+++ b/examples/ipsec-secgw/event_helper.c
@@ -0,0 +1,320 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) 2020 Marvell International Ltd.
+ */
+#include
+#include
+
+#include "event_helper.h"
+
+static int
+eh_set_default_conf_eventdev(struct eventmode_conf *em_conf)
+{
+ int lcore_count, nb_eventdev, nb_eth_dev, ret;
+ struct eventdev_params *eventdev_config;
+ struct rte_event_dev_info dev_info;
+
+ /* Get the number of event devices */
+ nb_eventdev = rte_event_dev_count();
+ if (nb_eventdev == 0) {
+ EH_LOG_ERR("No event devices detected");
+ return -EINVAL;
+ }
+
+ if (nb_eventdev != 1) {
+ EH_LOG_ERR("Event mode does not support multiple event devices.
"
+ "Please provide only one event device.");
+ return -EINVAL;
+ }
+
+ /* Get the number of eth devs */
+ nb_eth_dev = rte_eth_dev_count_avail();
+ if (nb_eth_dev == 0) {
+ EH_LOG_ERR("No eth devices detected");
+ return -EINVAL;
+ }
+
+ /* Get the number of lcores */
+ lcore_count = rte_lcore_count();
+
+ /* Read event device info */
+ ret = rte_event_dev_info_get(0, &dev_info);
+ if (ret < 0) {
+ EH_LOG_ERR("Failed to read event device info %d", ret);
+ return ret;
+ }
+
+ /* Check if enough ports are available */
+ if (dev_info.max_event_ports < 2) {
+ EH_LOG_ERR("Not enough event ports available");
+ return -EINVAL;
+ }
+
+ /* Get the first event dev conf */
+ eventdev_config = &(em_conf->eventdev_config[0]);
+
+ /* Save number of queues & ports available */
+ eventdev_config->eventdev_id = 0;
+ eventdev_config->nb_eventqueue = dev_info.max_event_queues;
+ eventdev_config->nb_eventport = dev_info.max_event_ports;
+ eventdev_config->ev_queue_mode = RTE_EVENT_QUEUE_CFG_ALL_TYPES;
+
+ /* Check if there are more queues than required */
+ if (eventdev_config->nb_eventqueue > nb_eth_dev + 1) {
+ /* One queue is reserved for Tx */
+ eventdev_config->nb_eventqueue = nb_eth_dev + 1;
+ }
+
+ /* Check if there are more ports than required */
+ if (eventdev_config->nb_eventport > lcore_count) {
+ /* One port per lcore is enough */
+ eventdev_config->nb_eventport = lcore_count;
+ }
+
+ /* Update the number of event devices */
+ em_conf->nb_eventdev++;
+
+ return 0;
+}
+
+static int
+eh_validate_conf(struct eventmode_conf *em_conf)
+{
+ int ret;
+
+ /*
+* Check if event devs are specified. Else probe the event devices
+* and initialize the config with all ports & queues available
+*/
+ if (em_conf->nb_eventdev == 0) {
+ ret = eh_set_default_conf_eventdev(em_conf);
+ if (ret != 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+eh_initialize_eventdev(struct eventmode_conf *em_conf)
+{
+ struct rte_event_queue_conf eventq_conf = {0};
+ struct rte_event_dev_info evdev_default_conf;
+ struct rte_event_dev_config eventdev_conf;
+ struct eventdev_params *eventdev_config;
+ int nb_eventdev = em_conf->nb_eventdev;
+ uint8_t eventdev_id;
+ int nb_eventqueue;
+ uint8_t i, j;
+ int ret;
+
+ for (i = 0; i < nb_eventdev; i++) {
+
+ /* Get eventdev config */
+ eventdev_config = &(em_conf->eventdev_config[i]);
+
+ /* Get event dev ID */
+ eventd
[dpdk-dev] [PATCH v5 03/15] examples/ipsec-secgw: add eventdev port-lcore link
From: Anoob Joseph
Add event device port-lcore link and specify which event queues should
be connected to the event port. Generate a default config for event
port-lcore links if it is not specified in the configuration. This
routine will check the number of available ports and then create links
according to the number of cores available. This patch also adds a new
entry in the eventmode conf to denote that all queues are to be linked
with every port. This enables one core to receive packets from all
ethernet ports.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 126
examples/ipsec-secgw/event_helper.h | 33 ++
2 files changed, 159 insertions(+)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index 0c38474..c90249f 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -1,11 +1,33 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright (C) 2020 Marvell International Ltd.
*/
+#include
#include
#include
+#include
#include "event_helper.h"
+static inline unsigned int
+eh_get_next_active_core(struct eventmode_conf *em_conf, unsigned int prev_core)
+{
+ unsigned int next_core;
+
+ /* Get next active core skipping cores reserved as eth cores */
+ do {
+ /* Get the next core */
+ next_core = rte_get_next_lcore(prev_core, 0, 0);
+
+ /* Check if we have reached max lcores */
+ if (next_core == RTE_MAX_LCORE)
+ return next_core;
+
+ prev_core = next_core;
+ } while (rte_bitmap_get(em_conf->eth_core_mask, next_core));
+
+ return next_core;
+}
+
static int
eh_set_default_conf_eventdev(struct eventmode_conf *em_conf)
{
@@ -77,6 +99,71 @@ eh_set_default_conf_eventdev(struct eventmode_conf *em_conf)
}
static int
+eh_set_default_conf_link(struct eventmode_conf *em_conf)
+{
+ struct eventdev_params *eventdev_config;
+ struct eh_event_link_info *link;
+ unsigned int lcore_id = -1;
+ int i, link_index;
+
+ /*
+* Create a 1:1 mapping from event ports to cores. If the number
+* of event ports is lesser than the cores, some cores won't
+* execute worker. If there are more event ports, then some ports
+* won't be used.
+*
+*/
+
+ /*
+* The event queue-port mapping is done according to the link. Since
+* we are falling back to the default link config, enabling
+* "all_ev_queue_to_ev_port" mode flag. This will map all queues
+* to the port.
+*/
+ em_conf->ext_params.all_ev_queue_to_ev_port = 1;
+
+ /* Get first event dev conf */
+ eventdev_config = &(em_conf->eventdev_config[0]);
+
+ /* Loop through the ports */
+ for (i = 0; i < eventdev_config->nb_eventport; i++) {
+
+ /* Get next active core id */
+ lcore_id = eh_get_next_active_core(em_conf,
+ lcore_id);
+
+ if (lcore_id == RTE_MAX_LCORE) {
+ /* Reached max cores */
+ return 0;
+ }
+
+ /* Save the current combination as one link */
+
+ /* Get the index */
+ link_index = em_conf->nb_link;
+
+ /* Get the corresponding link */
+ link = &(em_conf->link[link_index]);
+
+ /* Save link */
+ link->eventdev_id = eventdev_config->eventdev_id;
+ link->event_port_id = i;
+ link->lcore_id = lcore_id;
+
+ /*
+* Don't set eventq_id as by default all queues
+* need to be mapped to the port, which is controlled
+* by the operating mode.
+*/
+
+ /* Update number of links */
+ em_conf->nb_link++;
+ }
+
+ return 0;
+}
+
+static int
eh_validate_conf(struct eventmode_conf *em_conf)
{
int ret;
@@ -91,6 +178,16 @@ eh_validate_conf(struct eventmode_conf *em_conf)
return ret;
}
+ /*
+* Check if links are specified. Else generate a default config for
+* the event ports used.
+*/
+ if (em_conf->nb_link == 0) {
+ ret = eh_set_default_conf_link(em_conf);
+ if (ret != 0)
+ return ret;
+ }
+
return 0;
}
@@ -102,6 +199,8 @@ eh_initialize_eventdev(struct eventmode_conf *em_conf)
struct rte_event_dev_config eventdev_conf;
struct eventdev_params *eventdev_config;
int nb_eventdev = em_conf->nb_eventdev;
+ struct eh_event_link_info *link;
+ uint8_t *queue = NULL;
uint8_t eventdev_id;
int nb_eventqueue;
uint8_t i, j;
@@ -199,6 +298,33 @@ eh_initialize_eventdev(struct eve
[dpdk-dev] [PATCH v5 01/15] examples/ipsec-secgw: add default rte flow for inline Rx
From: Ankur Dwivedi
The default flow created would enable security processing on all ESP
packets. If the default flow is created, SA based rte_flow creation
would be skipped.
Signed-off-by: Ankur Dwivedi
Signed-off-by: Anoob Joseph
---
examples/ipsec-secgw/ipsec-secgw.c | 61 +-
examples/ipsec-secgw/ipsec.c | 5 +++-
examples/ipsec-secgw/ipsec.h | 6
3 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 4799bc9..e1ee7c3 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -129,6 +129,8 @@ struct ethaddr_info ethaddr_tbl[RTE_MAX_ETHPORTS] = {
{ 0, ETHADDR(0x00, 0x16, 0x3e, 0x49, 0x9e, 0xdd) }
};
+struct flow_info flow_info_tbl[RTE_MAX_ETHPORTS];
+
#define CMD_LINE_OPT_CONFIG"config"
#define CMD_LINE_OPT_SINGLE_SA "single-sa"
#define CMD_LINE_OPT_CRYPTODEV_MASK"cryptodev_mask"
@@ -2432,6 +2434,48 @@ reassemble_init(void)
return rc;
}
+static void
+create_default_ipsec_flow(uint16_t port_id, uint64_t rx_offloads)
+{
+ struct rte_flow_action action[2];
+ struct rte_flow_item pattern[2];
+ struct rte_flow_attr attr = {0};
+ struct rte_flow_error err;
+ struct rte_flow *flow;
+ int ret;
+
+ if (!(rx_offloads & DEV_RX_OFFLOAD_SECURITY))
+ return;
+
+ /* Add the default rte_flow to enable SECURITY for all ESP packets */
+
+ pattern[0].type = RTE_FLOW_ITEM_TYPE_ESP;
+ pattern[0].spec = NULL;
+ pattern[0].mask = NULL;
+ pattern[0].last = NULL;
+ pattern[1].type = RTE_FLOW_ITEM_TYPE_END;
+
+ action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
+ action[0].conf = NULL;
+ action[1].type = RTE_FLOW_ACTION_TYPE_END;
+ action[1].conf = NULL;
+
+ attr.ingress = 1;
+
+ ret = rte_flow_validate(port_id, &attr, pattern, action, &err);
+ if (ret)
+ return;
+
+ flow = rte_flow_create(port_id, &attr, pattern, action, &err);
+ if (flow == NULL)
+ return;
+
+ flow_info_tbl[port_id].rx_def_flow = flow;
+ RTE_LOG(INFO, IPSEC,
+ "Created default flow enabling SECURITY for all ESP traffic on
port %d\n",
+ port_id);
+}
+
int32_t
main(int32_t argc, char **argv)
{
@@ -2440,7 +2484,8 @@ main(int32_t argc, char **argv)
uint32_t i;
uint8_t socket_id;
uint16_t portid;
- uint64_t req_rx_offloads, req_tx_offloads;
+ uint64_t req_rx_offloads[RTE_MAX_ETHPORTS];
+ uint64_t req_tx_offloads[RTE_MAX_ETHPORTS];
size_t sess_sz;
/* init EAL */
@@ -2502,8 +2547,10 @@ main(int32_t argc, char **argv)
if ((enabled_port_mask & (1 << portid)) == 0)
continue;
- sa_check_offloads(portid, &req_rx_offloads, &req_tx_offloads);
- port_init(portid, req_rx_offloads, req_tx_offloads);
+ sa_check_offloads(portid, &req_rx_offloads[portid],
+ &req_tx_offloads[portid]);
+ port_init(portid, req_rx_offloads[portid],
+ req_tx_offloads[portid]);
}
cryptodevs_init();
@@ -2513,11 +2560,9 @@ main(int32_t argc, char **argv)
if ((enabled_port_mask & (1 << portid)) == 0)
continue;
- /*
-* Start device
-* note: device must be started before a flow rule
-* can be installed.
-*/
+ /* Create flow before starting the device */
+ create_default_ipsec_flow(portid, req_rx_offloads[portid]);
+
ret = rte_eth_dev_start(portid);
if (ret < 0)
rte_exit(EXIT_FAILURE, "rte_eth_dev_start: "
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 6e81207..d406571 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -275,6 +275,10 @@ create_inline_session(struct socket_ctx *skt_ctx, struct
ipsec_sa *sa,
unsigned int i;
unsigned int j;
+ /* Don't create flow if default flow is created */
+ if (flow_info_tbl[sa->portid].rx_def_flow)
+ return 0;
+
ret = rte_eth_dev_info_get(sa->portid, &dev_info);
if (ret != 0) {
RTE_LOG(ERR, IPSEC,
@@ -410,7 +414,6 @@ create_inline_session(struct socket_ctx *skt_ctx, struct
ipsec_sa *sa,
ips->security.ol_flags = sec_cap->ol_flags;
ips->security.ctx = sec_ctx;
}
- sa->cdev_id_qp = 0;
return 0;
}
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 4f2fd61..8f5d382
[dpdk-dev] [PATCH v5 04/15] examples/ipsec-secgw: add Rx adapter support
From: Anoob Joseph
Add Rx adapter support. The event helper init routine will initialize
the Rx adapter according to the configuration. If Rx adapter config
is not present it will generate a default config. If there are enough
event queues available it will map eth ports and event queues 1:1
(one eth port will be connected to one event queue). Otherwise it
will map all eth ports to one event queue.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 273 +++-
examples/ipsec-secgw/event_helper.h | 29
2 files changed, 301 insertions(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index c90249f..2653e86 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -4,10 +4,58 @@
#include
#include
#include
+#include
#include
+#include
#include "event_helper.h"
+static int
+eh_get_enabled_cores(struct rte_bitmap *eth_core_mask)
+{
+ int i, count = 0;
+
+ RTE_LCORE_FOREACH(i) {
+ /* Check if this core is enabled in core mask*/
+ if (rte_bitmap_get(eth_core_mask, i)) {
+ /* Found enabled core */
+ count++;
+ }
+ }
+ return count;
+}
+
+static inline unsigned int
+eh_get_next_eth_core(struct eventmode_conf *em_conf)
+{
+ static unsigned int prev_core = -1;
+ unsigned int next_core;
+
+ /*
+* Make sure we have at least one eth core running, else the following
+* logic would lead to an infinite loop.
+*/
+ if (eh_get_enabled_cores(em_conf->eth_core_mask) == 0) {
+ EH_LOG_ERR("No enabled eth core found");
+ return RTE_MAX_LCORE;
+ }
+
+ /* Only some cores are marked as eth cores, skip others */
+ do {
+ /* Get the next core */
+ next_core = rte_get_next_lcore(prev_core, 0, 1);
+
+ /* Check if we have reached max lcores */
+ if (next_core == RTE_MAX_LCORE)
+ return next_core;
+
+ /* Update prev_core */
+ prev_core = next_core;
+ } while (!(rte_bitmap_get(em_conf->eth_core_mask, next_core)));
+
+ return next_core;
+}
+
static inline unsigned int
eh_get_next_active_core(struct eventmode_conf *em_conf, unsigned int prev_core)
{
@@ -164,6 +212,82 @@ eh_set_default_conf_link(struct eventmode_conf *em_conf)
}
static int
+eh_set_default_conf_rx_adapter(struct eventmode_conf *em_conf)
+{
+ struct rx_adapter_connection_info *conn;
+ struct eventdev_params *eventdev_config;
+ struct rx_adapter_conf *adapter;
+ bool single_ev_queue = false;
+ int eventdev_id;
+ int nb_eth_dev;
+ int adapter_id;
+ int conn_id;
+ int i;
+
+ /* Create one adapter with eth queues mapped to event queue(s) */
+
+ if (em_conf->nb_eventdev == 0) {
+ EH_LOG_ERR("No event devs registered");
+ return -EINVAL;
+ }
+
+ /* Get the number of eth devs */
+ nb_eth_dev = rte_eth_dev_count_avail();
+
+ /* Use the first event dev */
+ eventdev_config = &(em_conf->eventdev_config[0]);
+
+ /* Get eventdev ID */
+ eventdev_id = eventdev_config->eventdev_id;
+ adapter_id = 0;
+
+ /* Get adapter conf */
+ adapter = &(em_conf->rx_adapter[adapter_id]);
+
+ /* Set adapter conf */
+ adapter->eventdev_id = eventdev_id;
+ adapter->adapter_id = adapter_id;
+ adapter->rx_core_id = eh_get_next_eth_core(em_conf);
+
+ /*
+* Map all queues of eth device (port) to an event queue. If there
+* are more event queues than eth ports then create 1:1 mapping.
+* Otherwise map all eth ports to a single event queue.
+*/
+ if (nb_eth_dev > eventdev_config->nb_eventqueue)
+ single_ev_queue = true;
+
+ for (i = 0; i < nb_eth_dev; i++) {
+
+ /* Use only the ports enabled */
+ if ((em_conf->eth_portmask & (1 << i)) == 0)
+ continue;
+
+ /* Get the connection id */
+ conn_id = adapter->nb_connections;
+
+ /* Get the connection */
+ conn = &(adapter->conn[conn_id]);
+
+ /* Set mapping between eth ports & event queues*/
+ conn->ethdev_id = i;
+ conn->eventq_id = single_ev_queue ? 0 : i;
+
+ /* Add all eth queues eth port to event queue */
+ conn->ethdev_rx_qid = -1;
+
+ /* Update no of connections */
+ adapter->nb_connections++;
+
+ }
+
+ /* We have setup one adapter */
+ em_conf->nb_rx_adapter = 1;
+
+ return 0;
+}
+
+static int
eh_validate_conf(struct eventmode_conf *em_conf)
{
int ret;
@@ -188,6 +312,16 @@
[dpdk-dev] [PATCH v5 06/15] examples/ipsec-secgw: add routines to display config
From: Anoob Joseph
Add routines to display the eventmode configuration and provide
an overview of the devices used.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 207
examples/ipsec-secgw/event_helper.h | 14 +++
2 files changed, 221 insertions(+)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index fca1e08..d09bf7d 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -816,6 +816,210 @@ eh_initialize_tx_adapter(struct eventmode_conf *em_conf)
return 0;
}
+static void
+eh_display_operating_mode(struct eventmode_conf *em_conf)
+{
+ char sched_types[][32] = {
+ "RTE_SCHED_TYPE_ORDERED",
+ "RTE_SCHED_TYPE_ATOMIC",
+ "RTE_SCHED_TYPE_PARALLEL",
+ };
+ EH_LOG_INFO("Operating mode:");
+
+ EH_LOG_INFO("\tScheduling type: \t%s",
+ sched_types[em_conf->ext_params.sched_type]);
+
+ EH_LOG_INFO("");
+}
+
+static void
+eh_display_event_dev_conf(struct eventmode_conf *em_conf)
+{
+ char queue_mode[][32] = {
+ "",
+ "ATQ (ALL TYPE QUEUE)",
+ "SINGLE LINK",
+ };
+ char print_buf[256] = { 0 };
+ int i;
+
+ EH_LOG_INFO("Event Device Configuration:");
+
+ for (i = 0; i < em_conf->nb_eventdev; i++) {
+ sprintf(print_buf,
+ "\tDev ID: %-2d \tQueues: %-2d \tPorts: %-2d",
+ em_conf->eventdev_config[i].eventdev_id,
+ em_conf->eventdev_config[i].nb_eventqueue,
+ em_conf->eventdev_config[i].nb_eventport);
+ sprintf(print_buf + strlen(print_buf),
+ "\tQueue mode: %s",
+ queue_mode[em_conf->eventdev_config[i].ev_queue_mode]);
+ EH_LOG_INFO("%s", print_buf);
+ }
+ EH_LOG_INFO("");
+}
+
+static void
+eh_display_rx_adapter_conf(struct eventmode_conf *em_conf)
+{
+ int nb_rx_adapter = em_conf->nb_rx_adapter;
+ struct rx_adapter_connection_info *conn;
+ struct rx_adapter_conf *adapter;
+ char print_buf[256] = { 0 };
+ int i, j;
+
+ EH_LOG_INFO("Rx adapters configured: %d", nb_rx_adapter);
+
+ for (i = 0; i < nb_rx_adapter; i++) {
+ adapter = &(em_conf->rx_adapter[i]);
+ EH_LOG_INFO(
+ "\tRx adaper ID: %-2d\tConnections: %-2d\tEvent dev ID:
%-2d"
+ "\tRx core: %-2d",
+ adapter->adapter_id,
+ adapter->nb_connections,
+ adapter->eventdev_id,
+ adapter->rx_core_id);
+
+ for (j = 0; j < adapter->nb_connections; j++) {
+ conn = &(adapter->conn[j]);
+
+ sprintf(print_buf,
+ "\t\tEthdev ID: %-2d", conn->ethdev_id);
+
+ if (conn->ethdev_rx_qid == -1)
+ sprintf(print_buf + strlen(print_buf),
+ "\tEth rx queue: %-2s", "ALL");
+ else
+ sprintf(print_buf + strlen(print_buf),
+ "\tEth rx queue: %-2d",
+ conn->ethdev_rx_qid);
+
+ sprintf(print_buf + strlen(print_buf),
+ "\tEvent queue: %-2d", conn->eventq_id);
+ EH_LOG_INFO("%s", print_buf);
+ }
+ }
+ EH_LOG_INFO("");
+}
+
+static void
+eh_display_tx_adapter_conf(struct eventmode_conf *em_conf)
+{
+ int nb_tx_adapter = em_conf->nb_tx_adapter;
+ struct tx_adapter_connection_info *conn;
+ struct tx_adapter_conf *adapter;
+ char print_buf[256] = { 0 };
+ int i, j;
+
+ EH_LOG_INFO("Tx adapters configured: %d", nb_tx_adapter);
+
+ for (i = 0; i < nb_tx_adapter; i++) {
+ adapter = &(em_conf->tx_adapter[i]);
+ sprintf(print_buf,
+ "\tTx adapter ID: %-2d\tConnections: %-2d\tEvent dev
ID: %-2d",
+ adapter->adapter_id,
+ adapter->nb_connections,
+ adapter->eventdev_id);
+ if (adapter->tx_core_id == (uint32_t)-1)
+ sprintf(print_buf + strlen(print_buf),
+ "\tTx core: %-2s", "[INTERNAL PORT]");
+ else if (adapter->tx_core_id == RTE_MAX_LCORE)
+ sprintf(print_buf + strlen(print_buf),
+ "\tTx core: %-2s", "[NONE]");
+ else
+ sprintf(print_buf + strlen(print_buf),
+ "\tTx core: %-2d,\tInput event queue: %-2d",
+
[dpdk-dev] [PATCH v5 07/15] examples/ipsec-secgw: add routines to launch workers
In eventmode workers can be drafted differently according to the
capabilities of the underlying event device. The added functions will
receive an array of such workers and probe the eventmode properties to
choose the worker.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 336
examples/ipsec-secgw/event_helper.h | 48 ++
2 files changed, 384 insertions(+)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index d09bf7d..e3dfaf5 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -11,6 +11,8 @@
#include "event_helper.h"
+static volatile bool eth_core_running;
+
static int
eh_get_enabled_cores(struct rte_bitmap *eth_core_mask)
{
@@ -93,6 +95,16 @@ eh_get_eventdev_params(struct eventmode_conf *em_conf,
uint8_t eventdev_id)
return &(em_conf->eventdev_config[i]);
}
+static inline bool
+eh_dev_has_burst_mode(uint8_t dev_id)
+{
+ struct rte_event_dev_info dev_info;
+
+ rte_event_dev_info_get(dev_id, &dev_info);
+ return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_BURST_MODE) ?
+ true : false;
+}
+
static int
eh_set_default_conf_eventdev(struct eventmode_conf *em_conf)
{
@@ -689,6 +701,257 @@ eh_initialize_rx_adapter(struct eventmode_conf *em_conf)
return 0;
}
+static int32_t
+eh_start_worker_eth_core(struct eventmode_conf *conf, uint32_t lcore_id)
+{
+ uint32_t service_id[EVENT_MODE_MAX_ADAPTERS_PER_RX_CORE];
+ struct rx_adapter_conf *rx_adapter;
+ struct tx_adapter_conf *tx_adapter;
+ int service_count = 0;
+ int adapter_id;
+ int32_t ret;
+ int i;
+
+ EH_LOG_INFO("Entering eth_core processing on lcore %u", lcore_id);
+
+ /*
+* Parse adapter config to check which of all Rx adapters need
+* to be handled by this core.
+*/
+ for (i = 0; i < conf->nb_rx_adapter; i++) {
+ /* Check if we have exceeded the max allowed */
+ if (service_count > EVENT_MODE_MAX_ADAPTERS_PER_RX_CORE) {
+ EH_LOG_ERR(
+ "Exceeded the max allowed adapters per rx core");
+ break;
+ }
+
+ rx_adapter = &(conf->rx_adapter[i]);
+ if (rx_adapter->rx_core_id != lcore_id)
+ continue;
+
+ /* Adapter is handled by this core */
+ adapter_id = rx_adapter->adapter_id;
+
+ /* Get the service ID for the adapters */
+ ret = rte_event_eth_rx_adapter_service_id_get(adapter_id,
+ &(service_id[service_count]));
+
+ if (ret != -ESRCH && ret < 0) {
+ EH_LOG_ERR(
+ "Failed to get service id used by rx adapter");
+ return ret;
+ }
+
+ /* Update service count */
+ service_count++;
+ }
+
+ /*
+* Parse adapter config to see which of all Tx adapters need
+* to be handled by this core.
+*/
+ for (i = 0; i < conf->nb_tx_adapter; i++) {
+ /* Check if we have exceeded the max allowed */
+ if (service_count > EVENT_MODE_MAX_ADAPTERS_PER_TX_CORE) {
+ EH_LOG_ERR(
+ "Exceeded the max allowed adapters per tx
core");
+ break;
+ }
+
+ tx_adapter = &conf->tx_adapter[i];
+ if (tx_adapter->tx_core_id != lcore_id)
+ continue;
+
+ /* Adapter is handled by this core */
+ adapter_id = tx_adapter->adapter_id;
+
+ /* Get the service ID for the adapters */
+ ret = rte_event_eth_tx_adapter_service_id_get(adapter_id,
+ &(service_id[service_count]));
+
+ if (ret != -ESRCH && ret < 0) {
+ EH_LOG_ERR(
+ "Failed to get service id used by tx adapter");
+ return ret;
+ }
+
+ /* Update service count */
+ service_count++;
+ }
+
+ eth_core_running = true;
+
+ while (eth_core_running) {
+ for (i = 0; i < service_count; i++) {
+ /* Initiate adapter service */
+ rte_service_run_iter_on_app_lcore(service_id[i], 0);
+ }
+ }
+
+ return 0;
+}
+
+static int32_t
+eh_stop_worker_eth_core(void)
+{
+ if (eth_core_running) {
+ EH_LOG_INFO("Stopping eth cores");
+ eth_core_running = false;
+ }
+ return 0;
+}
+
+static struct eh_app_worker_params *
+eh_find_worker(uint32_t lcore_id, struct eh_conf *conf,
+ struct eh_app_worker_params *ap
[dpdk-dev] [PATCH v5 05/15] examples/ipsec-secgw: add Tx adapter support
From: Anoob Joseph
Add Tx adapter support. The event helper init routine will initialize
the Tx adapter according to the configuration. If Tx adapter config
is not present it will generate a default config.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 313
examples/ipsec-secgw/event_helper.h | 48 ++
2 files changed, 361 insertions(+)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index 2653e86..fca1e08 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -76,6 +77,22 @@ eh_get_next_active_core(struct eventmode_conf *em_conf,
unsigned int prev_core)
return next_core;
}
+static struct eventdev_params *
+eh_get_eventdev_params(struct eventmode_conf *em_conf, uint8_t eventdev_id)
+{
+ int i;
+
+ for (i = 0; i < em_conf->nb_eventdev; i++) {
+ if (em_conf->eventdev_config[i].eventdev_id == eventdev_id)
+ break;
+ }
+
+ /* No match */
+ if (i == em_conf->nb_eventdev)
+ return NULL;
+
+ return &(em_conf->eventdev_config[i]);
+}
static int
eh_set_default_conf_eventdev(struct eventmode_conf *em_conf)
{
@@ -288,6 +305,95 @@ eh_set_default_conf_rx_adapter(struct eventmode_conf
*em_conf)
}
static int
+eh_set_default_conf_tx_adapter(struct eventmode_conf *em_conf)
+{
+ struct tx_adapter_connection_info *conn;
+ struct eventdev_params *eventdev_config;
+ struct tx_adapter_conf *tx_adapter;
+ int eventdev_id;
+ int adapter_id;
+ int nb_eth_dev;
+ int conn_id;
+ int i;
+
+ /*
+* Create one Tx adapter with all eth queues mapped to event queues
+* 1:1.
+*/
+
+ if (em_conf->nb_eventdev == 0) {
+ EH_LOG_ERR("No event devs registered");
+ return -EINVAL;
+ }
+
+ /* Get the number of eth devs */
+ nb_eth_dev = rte_eth_dev_count_avail();
+
+ /* Use the first event dev */
+ eventdev_config = &(em_conf->eventdev_config[0]);
+
+ /* Get eventdev ID */
+ eventdev_id = eventdev_config->eventdev_id;
+ adapter_id = 0;
+
+ /* Get adapter conf */
+ tx_adapter = &(em_conf->tx_adapter[adapter_id]);
+
+ /* Set adapter conf */
+ tx_adapter->eventdev_id = eventdev_id;
+ tx_adapter->adapter_id = adapter_id;
+
+ /* TODO: Tx core is required only when internal port is not present */
+ tx_adapter->tx_core_id = eh_get_next_eth_core(em_conf);
+
+ /*
+* Application uses one event queue per adapter for submitting
+* packets for Tx. Reserve the last queue available and decrement
+* the total available event queues for this
+*/
+
+ /* Queue numbers start at 0 */
+ tx_adapter->tx_ev_queue = eventdev_config->nb_eventqueue - 1;
+
+ /*
+* Map all Tx queues of the eth device (port) to the event device.
+*/
+
+ /* Set defaults for connections */
+
+ /*
+* One eth device (port) is one connection. Map all Tx queues
+* of the device to the Tx adapter.
+*/
+
+ for (i = 0; i < nb_eth_dev; i++) {
+
+ /* Use only the ports enabled */
+ if ((em_conf->eth_portmask & (1 << i)) == 0)
+ continue;
+
+ /* Get the connection id */
+ conn_id = tx_adapter->nb_connections;
+
+ /* Get the connection */
+ conn = &(tx_adapter->conn[conn_id]);
+
+ /* Add ethdev to connections */
+ conn->ethdev_id = i;
+
+ /* Add all eth tx queues to adapter */
+ conn->ethdev_tx_qid = -1;
+
+ /* Update no of connections */
+ tx_adapter->nb_connections++;
+ }
+
+ /* We have setup one adapter */
+ em_conf->nb_tx_adapter = 1;
+ return 0;
+}
+
+static int
eh_validate_conf(struct eventmode_conf *em_conf)
{
int ret;
@@ -322,6 +428,16 @@ eh_validate_conf(struct eventmode_conf *em_conf)
return ret;
}
+ /*
+* Check if tx adapters are specified. Else generate a default config
+* with one tx adapter.
+*/
+ if (em_conf->nb_tx_adapter == 0) {
+ ret = eh_set_default_conf_tx_adapter(em_conf);
+ if (ret != 0)
+ return ret;
+ }
+
return 0;
}
@@ -573,6 +689,133 @@ eh_initialize_rx_adapter(struct eventmode_conf *em_conf)
return 0;
}
+static int
+eh_tx_adapter_configure(struct eventmode_conf *em_conf,
+ struct tx_adapter_conf *adapter)
+{
+ struct rte_event_dev_info evdev_default_conf = {0};
+ struct rte_event_port_conf port_conf = {0};
+ str
[dpdk-dev] [PATCH v5 08/15] examples/ipsec-secgw: add support for internal ports
Add support for Rx and Tx internal ports. When internal ports are
available then a packet can be received from eth port and forwarded
to event queue by HW without any software intervention. The same
applies to Tx side where a packet sent to an event queue can by
forwarded by HW to eth port without any software intervention.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 179 +++-
examples/ipsec-secgw/event_helper.h | 11 +++
2 files changed, 167 insertions(+), 23 deletions(-)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index e3dfaf5..fe047ab 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -95,6 +95,39 @@ eh_get_eventdev_params(struct eventmode_conf *em_conf,
uint8_t eventdev_id)
return &(em_conf->eventdev_config[i]);
}
+
+static inline bool
+eh_dev_has_rx_internal_port(uint8_t eventdev_id)
+{
+ bool flag = true;
+ int j;
+
+ RTE_ETH_FOREACH_DEV(j) {
+ uint32_t caps = 0;
+
+ rte_event_eth_rx_adapter_caps_get(eventdev_id, j, &caps);
+ if (!(caps & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT))
+ flag = false;
+ }
+ return flag;
+}
+
+static inline bool
+eh_dev_has_tx_internal_port(uint8_t eventdev_id)
+{
+ bool flag = true;
+ int j;
+
+ RTE_ETH_FOREACH_DEV(j) {
+ uint32_t caps = 0;
+
+ rte_event_eth_tx_adapter_caps_get(eventdev_id, j, &caps);
+ if (!(caps & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT))
+ flag = false;
+ }
+ return flag;
+}
+
static inline bool
eh_dev_has_burst_mode(uint8_t dev_id)
{
@@ -175,6 +208,42 @@ eh_set_default_conf_eventdev(struct eventmode_conf
*em_conf)
return 0;
}
+static void
+eh_do_capability_check(struct eventmode_conf *em_conf)
+{
+ struct eventdev_params *eventdev_config;
+ int all_internal_ports = 1;
+ uint32_t eventdev_id;
+ int i;
+
+ for (i = 0; i < em_conf->nb_eventdev; i++) {
+
+ /* Get the event dev conf */
+ eventdev_config = &(em_conf->eventdev_config[i]);
+ eventdev_id = eventdev_config->eventdev_id;
+
+ /* Check if event device has internal port for Rx & Tx */
+ if (eh_dev_has_rx_internal_port(eventdev_id) &&
+ eh_dev_has_tx_internal_port(eventdev_id)) {
+ eventdev_config->all_internal_ports = 1;
+ } else {
+ all_internal_ports = 0;
+ }
+ }
+
+ /*
+* If Rx & Tx internal ports are supported by all event devices then
+* eth cores won't be required. Override the eth core mask requested
+* and decrement number of event queues by one as it won't be needed
+* for Tx.
+*/
+ if (all_internal_ports) {
+ rte_bitmap_reset(em_conf->eth_core_mask);
+ for (i = 0; i < em_conf->nb_eventdev; i++)
+ em_conf->eventdev_config[i].nb_eventqueue--;
+ }
+}
+
static int
eh_set_default_conf_link(struct eventmode_conf *em_conf)
{
@@ -246,7 +315,10 @@ eh_set_default_conf_rx_adapter(struct eventmode_conf
*em_conf)
struct rx_adapter_connection_info *conn;
struct eventdev_params *eventdev_config;
struct rx_adapter_conf *adapter;
+ bool rx_internal_port = true;
bool single_ev_queue = false;
+ int nb_eventqueue;
+ uint32_t caps = 0;
int eventdev_id;
int nb_eth_dev;
int adapter_id;
@@ -276,14 +348,21 @@ eh_set_default_conf_rx_adapter(struct eventmode_conf
*em_conf)
/* Set adapter conf */
adapter->eventdev_id = eventdev_id;
adapter->adapter_id = adapter_id;
- adapter->rx_core_id = eh_get_next_eth_core(em_conf);
+
+ /*
+* If event device does not have internal ports for passing
+* packets then reserved one queue for Tx path
+*/
+ nb_eventqueue = eventdev_config->all_internal_ports ?
+ eventdev_config->nb_eventqueue :
+ eventdev_config->nb_eventqueue - 1;
/*
* Map all queues of eth device (port) to an event queue. If there
* are more event queues than eth ports then create 1:1 mapping.
* Otherwise map all eth ports to a single event queue.
*/
- if (nb_eth_dev > eventdev_config->nb_eventqueue)
+ if (nb_eth_dev > nb_eventqueue)
single_ev_queue = true;
for (i = 0; i < nb_eth_dev; i++) {
@@ -305,11 +384,24 @@ eh_set_default_conf_rx_adapter(struct eventmode_conf
*em_conf)
/* Add all eth queues eth port to event queue */
conn->ethdev_rx_qid = -1;
+ /* Get Rx adapter capabilities */
+ rte_event
[dpdk-dev] [PATCH v5 09/15] examples/ipsec-secgw: add event helper config init/uninit
Add eventmode helper eh_conf_init and eh_conf_uninit
functions which purpose is to initialize and
unitialize eventmode helper configuration.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 103
examples/ipsec-secgw/event_helper.h | 23
2 files changed, 126 insertions(+)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index fe047ab..0854fc2 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -1379,6 +1379,109 @@ eh_display_link_conf(struct eventmode_conf *em_conf)
EH_LOG_INFO("");
}
+struct eh_conf *
+eh_conf_init(void)
+{
+ struct eventmode_conf *em_conf = NULL;
+ struct eh_conf *conf = NULL;
+ unsigned int eth_core_id;
+ void *bitmap = NULL;
+ uint32_t nb_bytes;
+
+ /* Allocate memory for config */
+ conf = calloc(1, sizeof(struct eh_conf));
+ if (conf == NULL) {
+ EH_LOG_ERR("Failed to allocate memory for eventmode helper "
+ "config");
+ return NULL;
+ }
+
+ /* Set default conf */
+
+ /* Packet transfer mode: poll */
+ conf->mode = EH_PKT_TRANSFER_MODE_POLL;
+
+ /* Keep all ethernet ports enabled by default */
+ conf->eth_portmask = -1;
+
+ /* Allocate memory for event mode params */
+ conf->mode_params = calloc(1, sizeof(struct eventmode_conf));
+ if (conf->mode_params == NULL) {
+ EH_LOG_ERR("Failed to allocate memory for event mode params");
+ goto free_conf;
+ }
+
+ /* Get eventmode conf */
+ em_conf = conf->mode_params;
+
+ /* Allocate and initialize bitmap for eth cores */
+ nb_bytes = rte_bitmap_get_memory_footprint(RTE_MAX_LCORE);
+ if (!nb_bytes) {
+ EH_LOG_ERR("Failed to get bitmap footprint");
+ goto free_em_conf;
+ }
+
+ bitmap = rte_zmalloc("event-helper-ethcore-bitmap", nb_bytes,
+RTE_CACHE_LINE_SIZE);
+ if (!bitmap) {
+ EH_LOG_ERR("Failed to allocate memory for eth cores bitmap\n");
+ goto free_em_conf;
+ }
+
+ em_conf->eth_core_mask = rte_bitmap_init(RTE_MAX_LCORE, bitmap,
+nb_bytes);
+ if (!em_conf->eth_core_mask) {
+ EH_LOG_ERR("Failed to initialize bitmap");
+ goto free_bitmap;
+ }
+
+ /* Set schedule type as not set */
+ em_conf->ext_params.sched_type = SCHED_TYPE_NOT_SET;
+
+ /* Set two cores as eth cores for Rx & Tx */
+
+ /* Use first core other than master core as Rx core */
+ eth_core_id = rte_get_next_lcore(0, /* curr core */
+1, /* skip master core */
+0 /* wrap */);
+
+ rte_bitmap_set(em_conf->eth_core_mask, eth_core_id);
+
+ /* Use next core as Tx core */
+ eth_core_id = rte_get_next_lcore(eth_core_id, /* curr core */
+1, /* skip master core */
+0 /* wrap */);
+
+ rte_bitmap_set(em_conf->eth_core_mask, eth_core_id);
+
+ return conf;
+
+free_bitmap:
+ rte_free(bitmap);
+free_em_conf:
+ free(em_conf);
+free_conf:
+ free(conf);
+ return NULL;
+}
+
+void
+eh_conf_uninit(struct eh_conf *conf)
+{
+ struct eventmode_conf *em_conf = NULL;
+
+ if (!conf || !conf->mode_params)
+ return;
+
+ /* Get eventmode conf */
+ em_conf = conf->mode_params;
+
+ /* Free evenmode configuration memory */
+ rte_free(em_conf->eth_core_mask);
+ free(em_conf);
+ free(conf);
+}
+
void
eh_display_conf(struct eh_conf *conf)
{
diff --git a/examples/ipsec-secgw/event_helper.h
b/examples/ipsec-secgw/event_helper.h
index 25c8563..e17cab1 100644
--- a/examples/ipsec-secgw/event_helper.h
+++ b/examples/ipsec-secgw/event_helper.h
@@ -46,6 +46,9 @@
/* Max adapters that one Tx core can handle */
#define EVENT_MODE_MAX_ADAPTERS_PER_TX_CORE EVENT_MODE_MAX_TX_ADAPTERS
+/* Used to indicate that queue schedule type is not set */
+#define SCHED_TYPE_NOT_SET 3
+
/**
* Packet transfer mode of the application
*/
@@ -200,6 +203,26 @@ struct eh_app_worker_params {
};
/**
+ * Allocate memory for event helper configuration and initialize
+ * it with default values.
+ *
+ * @return
+ * - pointer to event helper configuration structure on success.
+ * - NULL on failure.
+ */
+struct eh_conf *
+eh_conf_init(void);
+
+/**
+ * Uninitialize event helper configuration and release its memory
+. *
+ * @param conf
+ * Event helper configuration
+ */
+void
+eh_conf_uninit(struct eh_conf *conf);
+
+/**
* Initialize event mode devices
*
* Application can call this f
[dpdk-dev] [PATCH v5 10/15] examples/ipsec-secgw: add eventmode to ipsec-secgw
Add eventmode support to ipsec-secgw. With the aid of event helper
configure and use the eventmode capabilities.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/event_helper.c | 3 +
examples/ipsec-secgw/event_helper.h | 14 ++
examples/ipsec-secgw/ipsec-secgw.c | 301 +++-
examples/ipsec-secgw/ipsec.h| 24 +++
examples/ipsec-secgw/sa.c | 21 +--
examples/ipsec-secgw/sad.h | 5 -
6 files changed, 340 insertions(+), 28 deletions(-)
diff --git a/examples/ipsec-secgw/event_helper.c
b/examples/ipsec-secgw/event_helper.c
index 0854fc2..076f1f2 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -960,6 +960,8 @@ eh_find_worker(uint32_t lcore_id, struct eh_conf *conf,
else
curr_conf.cap.burst = EH_RX_TYPE_NON_BURST;
+ curr_conf.cap.ipsec_mode = conf->ipsec_mode;
+
/* Parse the passed list and see if we have matching capabilities */
/* Initialize the pointer used to traverse the list */
@@ -1400,6 +1402,7 @@ eh_conf_init(void)
/* Packet transfer mode: poll */
conf->mode = EH_PKT_TRANSFER_MODE_POLL;
+ conf->ipsec_mode = EH_IPSEC_MODE_TYPE_APP;
/* Keep all ethernet ports enabled by default */
conf->eth_portmask = -1;
diff --git a/examples/ipsec-secgw/event_helper.h
b/examples/ipsec-secgw/event_helper.h
index e17cab1..b65b343 100644
--- a/examples/ipsec-secgw/event_helper.h
+++ b/examples/ipsec-secgw/event_helper.h
@@ -73,6 +73,14 @@ enum eh_tx_types {
EH_TX_TYPE_NO_INTERNAL_PORT
};
+/**
+ * Event mode ipsec mode types
+ */
+enum eh_ipsec_mode_types {
+ EH_IPSEC_MODE_TYPE_APP = 0,
+ EH_IPSEC_MODE_TYPE_DRIVER
+};
+
/* Event dev params */
struct eventdev_params {
uint8_t eventdev_id;
@@ -182,6 +190,10 @@ struct eh_conf {
*/
void *mode_params;
/**< Mode specific parameters */
+
+ /** Application specific params */
+ enum eh_ipsec_mode_types ipsec_mode;
+ /**< Mode of ipsec run */
};
/* Workers registered by the application */
@@ -193,6 +205,8 @@ struct eh_app_worker_params {
/**< Specify status of rx type burst */
uint64_t tx_internal_port : 1;
/**< Specify whether tx internal port is available */
+ uint64_t ipsec_mode : 1;
+ /**< Specify ipsec processing level */
};
uint64_t u64;
} cap;
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index e1ee7c3..0f692d7 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -2,6 +2,7 @@
* Copyright(c) 2016 Intel Corporation
*/
+#include
#include
#include
#include
@@ -14,9 +15,11 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -41,13 +44,17 @@
#include
#include
#include
+#include
#include
#include
+#include "event_helper.h"
#include "ipsec.h"
#include "parser.h"
#include "sad.h"
+volatile bool force_quit;
+
#define RTE_LOGTYPE_IPSEC RTE_LOGTYPE_USER1
#define MAX_JUMBO_PKT_LEN 9600
@@ -134,12 +141,20 @@ struct flow_info flow_info_tbl[RTE_MAX_ETHPORTS];
#define CMD_LINE_OPT_CONFIG"config"
#define CMD_LINE_OPT_SINGLE_SA "single-sa"
#define CMD_LINE_OPT_CRYPTODEV_MASK"cryptodev_mask"
+#define CMD_LINE_OPT_TRANSFER_MODE "transfer-mode"
+#define CMD_LINE_OPT_SCHEDULE_TYPE "event-schedule-type"
#define CMD_LINE_OPT_RX_OFFLOAD"rxoffload"
#define CMD_LINE_OPT_TX_OFFLOAD"txoffload"
#define CMD_LINE_OPT_REASSEMBLE"reassemble"
#define CMD_LINE_OPT_MTU "mtu"
#define CMD_LINE_OPT_FRAG_TTL "frag-ttl"
+#define CMD_LINE_ARG_EVENT "event"
+#define CMD_LINE_ARG_POLL "poll"
+#define CMD_LINE_ARG_ORDERED "ordered"
+#define CMD_LINE_ARG_ATOMIC"atomic"
+#define CMD_LINE_ARG_PARALLEL "parallel"
+
enum {
/* long options mapped to a short option */
@@ -150,6 +165,8 @@ enum {
CMD_LINE_OPT_CONFIG_NUM,
CMD_LINE_OPT_SINGLE_SA_NUM,
CMD_LINE_OPT_CRYPTODEV_MASK_NUM,
+ CMD_LINE_OPT_TRANSFER_MODE_NUM,
+ CMD_LINE_OPT_SCHEDULE_TYPE_NUM,
CMD_LINE_OPT_RX_OFFLOAD_NUM,
CMD_LINE_OPT_TX_OFFLOAD_NUM,
CMD_LINE_OPT_REASSEMBLE_NUM,
@@ -161,6 +178,8 @@ static const struct option lgopts[] = {
{CMD_LINE_OPT_CONFIG, 1, 0, CMD_LINE_OPT_CONFIG_NUM},
{CMD_LINE_OPT_SINGLE_SA, 1, 0, CMD_LINE_OPT_SINGLE_SA_NUM},
{CMD_LINE_OPT_CRYPTODEV_MASK, 1, 0, CMD_LINE_OPT_CRYPTODEV_MASK_NUM},
+ {CMD_LINE_OPT_TRANSFER_MODE, 1, 0, CMD_LINE_OPT_TRANSFER_MODE_NUM},
+ {CMD_LINE_OPT_SCHEDULE_TYPE, 1, 0, CMD_LINE_OPT_SCHEDULE_TYPE_NUM},
{C
[dpdk-dev] [PATCH v5 13/15] examples/ipsec-secgw: make number of buffers dynamic
Make number of buffers in a pool nb_mbuf_in_pool dependent on number
of ports, cores and crypto queues. Add command line option -s which
when used overrides dynamic calculation of number of buffers in a pool.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/ipsec-secgw.c | 71 --
1 file changed, 60 insertions(+), 11 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index a03958d..5335c4c 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -60,8 +60,6 @@ volatile bool force_quit;
#define MEMPOOL_CACHE_SIZE 256
-#define NB_MBUF(32000)
-
#define CDEV_QUEUE_DESC 2048
#define CDEV_MAP_ENTRIES 16384
#define CDEV_MP_NB_OBJS 1024
@@ -164,6 +162,7 @@ static int32_t promiscuous_on = 1;
static int32_t numa_on = 1; /**< NUMA is enabled by default. */
static uint32_t nb_lcores;
static uint32_t single_sa;
+static uint32_t nb_bufs_in_pool;
/*
* RX/TX HW offload capabilities to enable/use on ethernet ports.
@@ -1280,6 +1279,7 @@ print_usage(const char *prgname)
" [-e]"
" [-a]"
" [-c]"
+ " [-s NUMBER_OF_MBUFS_IN_PKT_POOL]"
" -f CONFIG_FILE"
" --config (port,queue,lcore)[,(port,queue,lcore)]"
" [--single-sa SAIDX]"
@@ -1303,6 +1303,9 @@ print_usage(const char *prgname)
" -a enables SA SQN atomic behaviour\n"
" -c specifies inbound SAD cache size,\n"
" zero value disables the cache (default value: 128)\n"
+ " -s number of mbufs in packet pool, if not specified number\n"
+ " of mbufs will be calculated based on number of cores,\n"
+ " ports and crypto queues\n"
" -f CONFIG_FILE: Configuration file\n"
" --config (port,queue,lcore): Rx queue configuration. In
poll\n"
" mode determines which queues
from\n"
@@ -1507,7 +1510,7 @@ parse_args(int32_t argc, char **argv, struct eh_conf
*eh_conf)
argvopt = argv;
- while ((opt = getopt_long(argc, argvopt, "aelp:Pu:f:j:w:c:",
+ while ((opt = getopt_long(argc, argvopt, "aelp:Pu:f:j:w:c:s:",
lgopts, &option_index)) != EOF) {
switch (opt) {
@@ -1541,6 +1544,19 @@ parse_args(int32_t argc, char **argv, struct eh_conf
*eh_conf)
cfgfile = optarg;
f_present = 1;
break;
+
+ case 's':
+ ret = parse_decimal(optarg);
+ if (ret < 0) {
+ printf("Invalid number of buffers in a pool: "
+ "%s\n", optarg);
+ print_usage(prgname);
+ return -1;
+ }
+
+ nb_bufs_in_pool = ret;
+ break;
+
case 'j':
ret = parse_decimal(optarg);
if (ret < RTE_MBUF_DEFAULT_BUF_SIZE ||
@@ -1913,12 +1929,12 @@ check_cryptodev_mask(uint8_t cdev_id)
return -1;
}
-static int32_t
+static uint16_t
cryptodevs_init(void)
{
struct rte_cryptodev_config dev_conf;
struct rte_cryptodev_qp_conf qp_conf;
- uint16_t idx, max_nb_qps, qp, i;
+ uint16_t idx, max_nb_qps, qp, total_nb_qps, i;
int16_t cdev_id;
struct rte_hash_parameters params = { 0 };
@@ -1946,6 +1962,7 @@ cryptodevs_init(void)
printf("lcore/cryptodev/qp mappings:\n");
idx = 0;
+ total_nb_qps = 0;
for (cdev_id = 0; cdev_id < rte_cryptodev_count(); cdev_id++) {
struct rte_cryptodev_info cdev_info;
@@ -1979,6 +1996,7 @@ cryptodevs_init(void)
if (qp == 0)
continue;
+ total_nb_qps += qp;
dev_conf.socket_id = rte_cryptodev_socket_id(cdev_id);
dev_conf.nb_queue_pairs = qp;
dev_conf.ff_disable = RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO;
@@ -2011,7 +2029,7 @@ cryptodevs_init(void)
printf("\n");
- return 0;
+ return total_nb_qps;
}
static void
@@ -2665,20 +2683,36 @@ inline_sessions_free(struct sa_ctx *sa_ctx)
}
}
+static uint32_t
+calculate_nb_mbufs(uint16_t nb_ports, uint16_t nb_crypto_qp, uint32_t nb_rxq,
+ uint32_t nb_txq)
+{
+ return RTE_MAX((nb_rxq * nb_rxd +
+ nb_ports * nb_lcores * MAX_PKT_BURST +
+ nb_ports * nb_txq * nb_txd +
+ nb_lcores * MEMPOOL_CACHE_SIZE +
+ nb_crypto_qp * CDEV_QUEUE_DESC +
+ nb_lcores * frag_tbl_sz *
+ FRAG_TBL_BUCKET_ENTRIES),
+
[dpdk-dev] [PATCH v5 15/15] examples/ipsec-secgw: reserve crypto queues in event mode
Reserve minimum number of crypto queues equal to number of ports.
This is to fulfill inline protocol offload requirements.
Signed-off-by: Anoob Joseph
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/ipsec-secgw.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 5335c4c..ce36e6d 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1930,7 +1930,7 @@ check_cryptodev_mask(uint8_t cdev_id)
}
static uint16_t
-cryptodevs_init(void)
+cryptodevs_init(uint16_t req_queue_num)
{
struct rte_cryptodev_config dev_conf;
struct rte_cryptodev_qp_conf qp_conf;
@@ -1993,6 +1993,7 @@ cryptodevs_init(void)
i++;
}
+ qp = RTE_MIN(max_nb_qps, RTE_MAX(req_queue_num, qp));
if (qp == 0)
continue;
@@ -2761,7 +2762,16 @@ main(int32_t argc, char **argv)
sess_sz = max_session_size();
- nb_crypto_qp = cryptodevs_init();
+ /*
+* In event mode request minimum number of crypto queues
+* to be reserved equal to number of ports.
+*/
+ if (eh_conf->mode == EH_PKT_TRANSFER_MODE_EVENT)
+ nb_crypto_qp = rte_eth_dev_count_avail();
+ else
+ nb_crypto_qp = 0;
+
+ nb_crypto_qp = cryptodevs_init(nb_crypto_qp);
if (nb_bufs_in_pool == 0) {
RTE_ETH_FOREACH_DEV(portid) {
--
2.7.4
[dpdk-dev] [PATCH v5 12/15] examples/ipsec-secgw: add app mode worker
Add application inbound/outbound worker thread and
IPsec application processing code for event mode.
Example ipsec-secgw command in app mode:
ipsec-secgw -w 0002:02:00.0,ipsec_in_max_spi=128
-w 0002:03:00.0,ipsec_in_max_spi=128 -w 0002:0e:00.0 -w 0002:10:00.1
--log-level=8 -c 0x1 -- -P -p 0x3 -u 0x1 -f aes-gcm.cfg
--transfer-mode event --event-schedule-type parallel
Signed-off-by: Anoob Joseph
Signed-off-by: Ankur Dwivedi
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/ipsec-secgw.c | 31 +--
examples/ipsec-secgw/ipsec-secgw.h | 63 ++
examples/ipsec-secgw/ipsec.h| 16 --
examples/ipsec-secgw/ipsec_worker.c | 435 +++-
examples/ipsec-secgw/ipsec_worker.h | 41
5 files changed, 538 insertions(+), 48 deletions(-)
create mode 100644 examples/ipsec-secgw/ipsec_worker.h
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 9ad4be5..a03958d 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -50,13 +50,12 @@
#include "event_helper.h"
#include "ipsec.h"
+#include "ipsec_worker.h"
#include "parser.h"
#include "sad.h"
volatile bool force_quit;
-#define RTE_LOGTYPE_IPSEC RTE_LOGTYPE_USER1
-
#define MAX_JUMBO_PKT_LEN 9600
#define MEMPOOL_CACHE_SIZE 256
@@ -86,29 +85,6 @@ volatile bool force_quit;
static uint16_t nb_rxd = IPSEC_SECGW_RX_DESC_DEFAULT;
static uint16_t nb_txd = IPSEC_SECGW_TX_DESC_DEFAULT;
-#if RTE_BYTE_ORDER != RTE_LITTLE_ENDIAN
-#define __BYTES_TO_UINT64(a, b, c, d, e, f, g, h) \
- (((uint64_t)((a) & 0xff) << 56) | \
- ((uint64_t)((b) & 0xff) << 48) | \
- ((uint64_t)((c) & 0xff) << 40) | \
- ((uint64_t)((d) & 0xff) << 32) | \
- ((uint64_t)((e) & 0xff) << 24) | \
- ((uint64_t)((f) & 0xff) << 16) | \
- ((uint64_t)((g) & 0xff) << 8) | \
- ((uint64_t)(h) & 0xff))
-#else
-#define __BYTES_TO_UINT64(a, b, c, d, e, f, g, h) \
- (((uint64_t)((h) & 0xff) << 56) | \
- ((uint64_t)((g) & 0xff) << 48) | \
- ((uint64_t)((f) & 0xff) << 40) | \
- ((uint64_t)((e) & 0xff) << 32) | \
- ((uint64_t)((d) & 0xff) << 24) | \
- ((uint64_t)((c) & 0xff) << 16) | \
- ((uint64_t)((b) & 0xff) << 8) | \
- ((uint64_t)(a) & 0xff))
-#endif
-#define ETHADDR(a, b, c, d, e, f) (__BYTES_TO_UINT64(a, b, c, d, e, f, 0, 0))
-
#define ETHADDR_TO_UINT64(addr) __BYTES_TO_UINT64( \
(addr)->addr_bytes[0], (addr)->addr_bytes[1], \
(addr)->addr_bytes[2], (addr)->addr_bytes[3], \
@@ -120,11 +96,6 @@ static uint16_t nb_txd = IPSEC_SECGW_TX_DESC_DEFAULT;
#define MTU_TO_FRAMELEN(x) ((x) + RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN)
-/* port/source ethernet addr and destination ethernet addr */
-struct ethaddr_info {
- uint64_t src, dst;
-};
-
struct ethaddr_info ethaddr_tbl[RTE_MAX_ETHPORTS] = {
{ 0, ETHADDR(0x00, 0x16, 0x3e, 0x7e, 0x94, 0x9a) },
{ 0, ETHADDR(0x00, 0x16, 0x3e, 0x22, 0xa1, 0xd9) },
diff --git a/examples/ipsec-secgw/ipsec-secgw.h
b/examples/ipsec-secgw/ipsec-secgw.h
index a07a920..4b53cb5 100644
--- a/examples/ipsec-secgw/ipsec-secgw.h
+++ b/examples/ipsec-secgw/ipsec-secgw.h
@@ -8,6 +8,69 @@
#define NB_SOCKETS 4
+#define MAX_PKT_BURST 32
+
+#define RTE_LOGTYPE_IPSEC RTE_LOGTYPE_USER1
+
+#if RTE_BYTE_ORDER != RTE_LITTLE_ENDIAN
+#define __BYTES_TO_UINT64(a, b, c, d, e, f, g, h) \
+ (((uint64_t)((a) & 0xff) << 56) | \
+ ((uint64_t)((b) & 0xff) << 48) | \
+ ((uint64_t)((c) & 0xff) << 40) | \
+ ((uint64_t)((d) & 0xff) << 32) | \
+ ((uint64_t)((e) & 0xff) << 24) | \
+ ((uint64_t)((f) & 0xff) << 16) | \
+ ((uint64_t)((g) & 0xff) << 8) | \
+ ((uint64_t)(h) & 0xff))
+#else
+#define __BYTES_TO_UINT64(a, b, c, d, e, f, g, h) \
+ (((uint64_t)((h) & 0xff) << 56) | \
+ ((uint64_t)((g) & 0xff) << 48) | \
+ ((uint64_t)((f) & 0xff) << 40) | \
+ ((uint64_t)((e) & 0xff) << 32) | \
+ ((uint64_t)((d) & 0xff) << 24) | \
+ ((uint64_t)((c) & 0xff) << 16) | \
+ ((uint64_t)((b) & 0xff) << 8) | \
+ ((uint64_t)(a) & 0xff))
+#endif
+
+#define ETHADDR(a, b, c, d, e, f) (__BYTES_TO_UINT64(a, b, c, d, e, f, 0, 0))
+
+struct traffic_type {
+ const uint8_t *data[MAX_PKT_BURST * 2];
+ struct rte_mbuf *pkts[MAX_PKT_BURST * 2];
+ void *saptr[MAX_PKT_BURST * 2];
+ uint32_t res[MAX_PKT_BURST * 2];
+ uint32_t num;
+};
+
+struct ipsec_traffic {
+ struct traffic_type ipsec;
+ struct traffic_type ip4;
+ struct traffic_type ip6;
+};
+
+/* Fields optimized for devices without burst */
+struct traffic_type_nb {
+ const uint8_t *data;
+ struct rte_mbuf *pkt;
+ uint32_t res;
+ uint32_t num;
+};
+
+struct ipsec_traffic_nb {
+ struct traffic_type_nb ipsec;
+ struct traffic_type_nb ip4;
+ struct traffic_type_nb ip6;
+};
+
+/* port/source ethernet addr and destination ethernet add
[dpdk-dev] [PATCH v5 14/15] doc: add event mode support to ipsec-secgw
Document addition of event mode support to ipsec-secgw application. Signed-off-by: Anoob Joseph Signed-off-by: Lukasz Bartosik --- doc/guides/sample_app_ug/ipsec_secgw.rst | 135 ++- 1 file changed, 113 insertions(+), 22 deletions(-) diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst index 5ec9b1e..038f593 100644 --- a/doc/guides/sample_app_ug/ipsec_secgw.rst +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2016-2017 Intel Corporation. +Copyright (C) 2020 Marvell International Ltd. IPsec Security Gateway Sample Application = @@ -61,6 +62,44 @@ The Path for the IPsec Outbound traffic is: * Routing. * Write packet to port. +The application supports two modes of operation: poll mode and event mode. + +* In the poll mode a core receives packets from statically configured list + of eth ports and eth ports' queues. + +* In the event mode a core receives packets as events. After packet processing + is done core submits them back as events to an event device. This enables + multicore scaling and HW assisted scheduling by making use of the event device + capabilities. The event mode configuration is predefined. All packets reaching + given eth port will arrive at the same event queue. All event queues are mapped + to all event ports. This allows all cores to receive traffic from all ports. + Since the underlying event device might have varying capabilities, the worker + threads can be drafted differently to maximize performance. For example, if an + event device - eth device pair has Tx internal port, then application can call + rte_event_eth_tx_adapter_enqueue() instead of regular rte_event_enqueue_burst(). + So a thread which assumes that the device pair has internal port will not be the + right solution for another pair. The infrastructure added for the event mode aims + to help application to have multiple worker threads by maximizing performance from + every type of event device without affecting existing paths/use cases. The worker + to be used will be determined by the operating conditions and the underlying device + capabilities. **Currently the application provides non-burst, internal port worker + threads and supports inline protocol only.** It also provides infrastructure for + non-internal port however does not define any worker threads. + +Additionally the event mode introduces two submodes of processing packets: + +* Driver submode: This submode has bare minimum changes in the application to support + IPsec. There are no lookups, no routing done in the application. And for inline + protocol use case, the worker thread resembles l2fwd worker thread as the IPsec + processing is done entirely in HW. This mode can be used to benchmark the raw + performance of the HW. The driver submode is selected with --single-sa option + (used also by poll mode). When --single-sa option is used in conjution with event + mode then index passed to --single-sa is ignored. + +* App submode: This submode has all the features currently implemented with the + application (non librte_ipsec path). All the lookups, routing follows existing + methods and report numbers that can be compared against regular poll mode + benchmark numbers. Constraints --- @@ -94,13 +133,18 @@ The application has a number of command line options:: -p PORTMASK -P -u PORTMASK -j FRAMESIZE -l -w REPLAY_WINOW_SIZE -e -a -c SAD_CACHE_SIZE ---config (port,queue,lcore)[,(port,queue,lcore] +-s NUMBER_OF_MBUFS_IN_PACKET_POOL +-f CONFIG_FILE_PATH +--config (port,queue,lcore)[,(port,queue,lcore)] --single-sa SAIDX +--cryptodev_mask MASK +--transfer-mode MODE +--event-schedule-type TYPE --rxoffload MASK --txoffload MASK ---mtu MTU --reassemble NUM --f CONFIG_FILE_PATH +--mtu MTU +--frag-ttl FRAG_TTL_NS Where: @@ -138,12 +182,37 @@ Where: Zero value disables cache. Default value: 128. -* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues -from which ports are mapped to which cores. +* ``-s``: sets number of mbufs in packet pool, if not provided number of mbufs +will be calculated based on number of cores, eth ports and crypto queues. + +* ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all +configuration items for running the application (See Configuration file +syntax section below). `
[dpdk-dev] [PATCH v5 11/15] examples/ipsec-secgw: add driver mode worker
Add driver inbound and outbound worker thread for ipsec-secgw. In driver
mode application does as little as possible. It simply forwards packets
back to port from which traffic was received instructing HW to apply
inline security processing using first outbound SA configured for
a given port. If a port does not have SA configured outbound traffic
on that port will be silently dropped. The aim of this mode is to
measure HW capabilities. Driver mode is selected with single-sa option.
The single-sa option accepts SA index however in event mode the SA
index is ignored.
Example command to run ipsec-secgw in driver mode:
ipsec-secgw -w 0002:02:00.0,ipsec_in_max_spi=128
-w 0002:03:00.0,ipsec_in_max_spi=128 -w 0002:0e:00.0 -w 0002:10:00.1
--log-level=8 -c 0x1 -- -P -p 0x3 -u 0x1 -f aes-gcm.cfg
--transfer-mode event --event-schedule-type parallel --single-sa 0
Signed-off-by: Anoob Joseph
Signed-off-by: Ankur Dwivedi
Signed-off-by: Lukasz Bartosik
---
examples/ipsec-secgw/Makefile | 1 +
examples/ipsec-secgw/ipsec-secgw.c | 34 +++---
examples/ipsec-secgw/ipsec-secgw.h | 25 +
examples/ipsec-secgw/ipsec.h| 11 ++
examples/ipsec-secgw/ipsec_worker.c | 218
examples/ipsec-secgw/meson.build| 2 +-
6 files changed, 272 insertions(+), 19 deletions(-)
create mode 100644 examples/ipsec-secgw/ipsec-secgw.h
create mode 100644 examples/ipsec-secgw/ipsec_worker.c
diff --git a/examples/ipsec-secgw/Makefile b/examples/ipsec-secgw/Makefile
index 66d05d4..c4a272a 100644
--- a/examples/ipsec-secgw/Makefile
+++ b/examples/ipsec-secgw/Makefile
@@ -16,6 +16,7 @@ SRCS-y += sad.c
SRCS-y += rt.c
SRCS-y += ipsec_process.c
SRCS-y += ipsec-secgw.c
+SRCS-y += ipsec_worker.c
SRCS-y += event_helper.c
CFLAGS += -gdwarf-2
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 0f692d7..9ad4be5 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -71,8 +71,6 @@ volatile bool force_quit;
#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
-#define NB_SOCKETS 4
-
/* Configure how many packets ahead to prefetch, when reading packets */
#define PREFETCH_OFFSET3
@@ -80,8 +78,6 @@ volatile bool force_quit;
#define MAX_LCORE_PARAMS 1024
-#define UNPROTECTED_PORT(port) (unprotected_port_mask & (1 << portid))
-
/*
* Configurable number of RX/TX ring descriptors
*/
@@ -188,15 +184,15 @@ static const struct option lgopts[] = {
{NULL, 0, 0, 0}
};
+uint32_t unprotected_port_mask;
+uint32_t single_sa_idx;
/* mask of enabled ports */
static uint32_t enabled_port_mask;
static uint64_t enabled_cryptodev_mask = UINT64_MAX;
-static uint32_t unprotected_port_mask;
static int32_t promiscuous_on = 1;
static int32_t numa_on = 1; /**< NUMA is enabled by default. */
static uint32_t nb_lcores;
static uint32_t single_sa;
-static uint32_t single_sa_idx;
/*
* RX/TX HW offload capabilities to enable/use on ethernet ports.
@@ -282,7 +278,7 @@ static struct rte_eth_conf port_conf = {
},
};
-static struct socket_ctx socket_ctx[NB_SOCKETS];
+struct socket_ctx socket_ctx[NB_SOCKETS];
/*
* Determine is multi-segment support required:
@@ -1003,12 +999,12 @@ process_pkts(struct lcore_conf *qconf, struct rte_mbuf
**pkts,
prepare_traffic(pkts, &traffic, nb_pkts);
if (unlikely(single_sa)) {
- if (UNPROTECTED_PORT(portid))
+ if (is_unprotected_port(portid))
process_pkts_inbound_nosp(&qconf->inbound, &traffic);
else
process_pkts_outbound_nosp(&qconf->outbound, &traffic);
} else {
- if (UNPROTECTED_PORT(portid))
+ if (is_unprotected_port(portid))
process_pkts_inbound(&qconf->inbound, &traffic);
else
process_pkts_outbound(&qconf->outbound, &traffic);
@@ -1119,8 +1115,8 @@ drain_outbound_crypto_queues(const struct lcore_conf
*qconf,
}
/* main processing loop */
-static int32_t
-main_loop(__attribute__((unused)) void *dummy)
+void
+ipsec_poll_mode_worker(void)
{
struct rte_mbuf *pkts[MAX_PKT_BURST];
uint32_t lcore_id;
@@ -1164,13 +1160,13 @@ main_loop(__attribute__((unused)) void *dummy)
RTE_LOG(ERR, IPSEC,
"SAD cache init on lcore %u, failed with code: %d\n",
lcore_id, rc);
- return rc;
+ return;
}
if (qconf->nb_rx_queue == 0) {
RTE_LOG(DEBUG, IPSEC, "lcore %u has nothing to do\n",
lcore_id);
- return 0;
+ return;
}
RTE_LOG(INFO, IPSEC, "entering main loop on lcore %u\n", lcore_id);
@@ -1183,7 +1179,7 @@ main_loop(__attribute__((unused)) void *dummy)
lcore_id, portid, queueid);
}
- while (1) {
+ whi
Re: [dpdk-dev] [PATCH v1] net/axgbe: add register dump support
On 2/16/2020 6:47 AM, Kumar, Ravi1 wrote: <...> >> >> -Original Message- >> From: Namburu, Chandu-babu >> Sent: Tuesday, February 11, 2020 3:58 PM >> To: dev@dpdk.org >> Cc: Kumar, Ravi1 ; Somalapuram, Amaranath >> >> Subject: [PATCH v1] net/axgbe: add register dump support >> >> From: Chandu Babu N >> >> Implement "get_reg" eth_dev_ops for axgbe >> >> Signed-off-by: Chandu Babu N > > Acked-by: Ravi Kumar > Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 1/2] net/memif: enable loopback
On 2/19/2020 8:18 AM, Július Milan wrote: > With this patch it is possible to connect 2 DPDK memifs into loopback, > i.e. when they have the same id and different roles, as for example: > "--vdev=net_memif0,role=master,id=0" > "--vdev=net_memif1,role=slave,id=0" > > Signed-off-by: Július Milan > --- > drivers/net/memif/memif_socket.c | 30 ++ > drivers/net/memif/rte_eth_memif.c | 1 + > drivers/net/memif/rte_eth_memif.h | 1 + > 3 files changed, 16 insertions(+), 16 deletions(-) Hi Július, Can you please document this new feature in the memif documentation, and it may be good to give a sample testpmd commands like ones already exist in that doc? Thanks, ferruh
Re: [dpdk-dev] Questions about rte_timer APIs
Thanks Erik. We will create some patches and send them for review. > -Original Message- > From: Carrillo, Erik G > Sent: Wednesday, February 26, 2020 10:58 AM > To: Honnappa Nagarahalli ; Robert > Sanford > Cc: dev ; nd ; Phil Yang > ; Gavin Hu ; > david.march...@redhat.com; tho...@monjalon.net; nd > Subject: RE: Questions about rte_timer APIs > > Hi Honnappa, > > Your description below looks correct to me. For the current implementation, I > referenced a couple of existing DPDK libraries, but primarily the rte_service > library. However, I agree that allocating the timer data structs only as > needed > would be a good idea. > > You are also correct that, since the rte_timer_alt_* APIs are still > experimental, > they can change without constraint; this would allow for the APIs to change > as needed to support the above design. It looks like the only users of those > APIs in DPDK currently are the event timer adapter and unit test code. > > Thanks, > Erik > > > -Original Message- > > From: Honnappa Nagarahalli > > Sent: Tuesday, February 25, 2020 5:56 PM > > To: Honnappa Nagarahalli ; Robert > > Sanford ; Carrillo, Erik G > > > > Cc: dev ; nd ; Phil Yang > > ; Gavin Hu ; > > david.march...@redhat.com; tho...@monjalon.net; nd > > Subject: RE: Questions about rte_timer APIs > > > > Hi Erik, > > I see that the rte_timer_alt_xxx APIs are still marked as > > experimental. So, we should be able to change them without any ABI > > constraints. Please let me know what you think. > > > > Thank you, > > Honnappa > > > > > -Original Message- > > > From: dev On Behalf Of Honnappa Nagarahalli > > > Sent: Thursday, February 13, 2020 11:55 PM > > > To: Robert Sanford ; Erik Gabriel Carrillo > > > > > > Cc: dev ; nd ; Phil Yang > > > ; Gavin Hu ; nd > > > > > Subject: [dpdk-dev] Questions about rte_timer APIs > > > > > > Hi Erik/Robert, > > > I was looking at the rte_timer library code and have questions > > > around the way instances of timer list are allocated. > > > > > > The API 'rte_timer_subsystem_init' allocates RTE_MAX_DATA_ELS (64) > > > number of timer data structs. Each timer data struct acts as an > > > independent instance of timer list. The user allocates an instance > > > by calling 'rte_timer_data_alloc' which provides an index in the > > > instance array.to s Essentially, the library is allocating the > > > memory upfront even though there might not be a need to have 64 > > > instances. Please correct me if I am > > wrong. > > > > > > Usually, creating multiple instances is handled by allocating > > > required memory, as and when required, by an 'init' API. This API > > > also returns a pointer to that instance which is passed to other > > > APIs in the library. For ex: rte_hash library follows this approach. > > > IMO, this is an > > elegant way to handle multiple instances. > > > This approach does not waste memory and does not put any restriction > > > on number of instances. > > > > > > I wanted to understand the reasoning behind the current design to > > > handle multiple instances. Appreciate your inputs. > > > > > > Thank you, > > > Honnappa
Re: [dpdk-dev] [PATCH 1/2] net/memif: enable loopback
On 2/19/2020 8:18 AM, Július Milan wrote:
> With this patch it is possible to connect 2 DPDK memifs into loopback,
> i.e. when they have the same id and different roles, as for example:
> "--vdev=net_memif0,role=master,id=0"
> "--vdev=net_memif1,role=slave,id=0"
>
> Signed-off-by: Július Milan
<...>
> @@ -642,8 +645,12 @@ memif_msg_receive(struct memif_control_channel *cc)
>
> size = recvmsg(cc->intr_handle.fd, &mh, 0);
> if (size != sizeof(memif_msg_t)) {
> - MIF_LOG(DEBUG, "Invalid message size.");
> - memif_msg_enq_disconnect(cc, "Invalid message size", 0);
> + MIF_LOG(DEBUG, "Invalid message size = %ld", size);
'size' type is 'size_t', can you please use correct format specifier '%zu' for
it?
This will fix the 32-bit build.
Re: [dpdk-dev] [PATCH 1/2] net/bonding: fix MAC address when switching active port
On 2/25/2020 9:29 AM, Wei Hu (Xavier) wrote:
> From: "Wei Hu (Xavier)"
>
> Currently, based on a active-backup bond device, when the link status of
> the primary port changes from up to down, one slave port changes to the
> primary port, but the new primary port's MAC address cannot change to the
> bond device's MAC address. And we can't continue receive packets whose
> destination MAC addresses are the same as the bond devices's MAC address.
>
> The current bonding PMD driver call mac_address_slaves_update function to
> modify the MAC address of all slaves devices: the primary port using bond
> device's MAC address, and other slaves devices using the respective MAC
> address. We found that one error using primary_port instead of
> current_primary_port in mac_address_slaves_update function.
>
> On the other hand, The current bonding PMD driver sets slave devices's MAC
> address according to the variable named current_primary_port. The variable
> named current_primary_port changes in the following scenario:
> 1. Add the slave devices to bond, the first slave port will be regardes as
>the current_primary_port. If changing the order of adding the slave
>devices, the value of the variable named current_primary_port will be
>different.
> 2. The upper application specifies primary_port via calling the
>rte_eth_bond_primary_set API function.
> 3. Delete the primary slave device.
> 4. The link status of the primary port changes from up to down.
>
> We have tested the above 4 cases and found that there are problems that
> the new primary port's MAC address didn't change to the bond device's MAC
> address when running case 3 and 4. When current_primary_port changes, the
> new primary port's MAC address should change at the same time. We also need
> to call mac_address_slaves_update function to update MAC addresses in case
> 3 and 4.
>
> For more details please refer to:
> https://bugs.dpdk.org/show_bug.cgi?id=256
>
> Bugzilla ID: 256
> Fixes: 2efb58cbab6e ("bond: new link bonding library")
> Cc: sta...@dpdk.org
>
> Reported-by: Chunsong Feng
> Signed-off-by: Chunsong Feng
> Signed-off-by: Wei Hu (Xavier)
Please cc the maintainer on the patches. cc'ed Chas for this one.
I am using './devtools/get-maintainer.sh' script, once you set it up, it helps a
lot.
[dpdk-dev] [PATCH] telemetry: fix struct reset after value assignment
The ep struct is used to track what type of stats are required by the
client. For PORT_STATS type, it contains the lists of port and metric
ids to query, and the number of ids in each list.
The ep struct has values set (num of port and metric ids) when a request
for port stats values by name is received. However, after this value
assignment, the struct is reset to all 0 values, meaning the number of
port and metric ids required now both show as 0, and the client will not
receive the requested data in response. To fix this issue, the memset
call is now moved above the ep struct value assignment.
Fixes: 4080e46c8078 ("telemetry: support global metrics")
Cc: reshma.pat...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
---
lib/librte_telemetry/rte_telemetry_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_telemetry/rte_telemetry_parser.c
b/lib/librte_telemetry/rte_telemetry_parser.c
index 960132397..e8c269e85 100644
--- a/lib/librte_telemetry/rte_telemetry_parser.c
+++ b/lib/librte_telemetry/rte_telemetry_parser.c
@@ -456,9 +456,9 @@ rte_telemetry_command_ports_stats_values_by_name(struct
telemetry_impl
size_t index;
json_t *value;
+ memset(&ep, 0, sizeof(ep));
ep.pp.num_port_ids = json_array_size(port_ids_json);
ep.pp.num_metric_ids = num_stat_names;
- memset(&ep, 0, sizeof(ep));
if (telemetry == NULL) {
TELEMETRY_LOG_ERR("Invalid telemetry argument");
return -1;
--
2.17.1
Re: [dpdk-dev] [PATCH] af_packet: allow configuring number of rings
On 2/24/2020 11:11 PM, Stephen Hemminger wrote: > The maximum number of rings in af_packet is hard coded as 16. > The user should be able to configure this as part of DPDK config. > > Signed-off-by: Stephen Hemminger > --- > config/common_base| 1 + > drivers/net/af_packet/rte_eth_af_packet.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/config/common_base b/config/common_base > index 6ea9c63cc36b..dd154a474b57 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -468,6 +468,7 @@ CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n > # Compile software PMD backed by AF_PACKET sockets (Linux only) > # > CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n > +CONFIG_RTE_PMD_AF_PACKET_MAX_RINGS=16 > Not sure about adding a new config option for this. There is already "qpairs" devarg, allocating queues dynamically, instead of using a per-defined sized arrays, should enable removing 'RTE_PMD_AF_PACKET_MAX_RINGS' completely.
Re: [dpdk-dev] [PATCH] telemetry: fix struct reset after value assignment
> The ep struct is used to track what type of stats are required by the client.
> For PORT_STATS type, it contains the lists of port and metric ids to query,
> and
> the number of ids in each list.
>
> The ep struct has values set (num of port and metric ids) when a request for
> port stats values by name is received. However, after this value assignment,
> the struct is reset to all 0 values, meaning the number of port and metric ids
> required now both show as 0, and the client will not receive the requested
> data in response. To fix this issue, the memset call is now moved above the
> ep struct value assignment.
>
> Fixes: 4080e46c8078 ("telemetry: support global metrics")
> Cc: reshma.pat...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
Reviewed-by: Kevin Laatz
Re: [dpdk-dev] [PATCH v2 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user
On Wed, 19 Feb 2020 11:54:18 -0700
Alex Williamson wrote:
> The VFIO_DEVICE_FEATURE ioctl is meant to be a general purpose, device
> agnostic ioctl for setting, retrieving, and probing device features.
> This implementation provides a 16-bit field for specifying a feature
> index, where the data porition of the ioctl is determined by the
> semantics for the given feature. Additional flag bits indicate the
> direction and nature of the operation; SET indicates user data is
> provided into the device feature, GET indicates the device feature is
> written out into user data. The PROBE flag augments determining
> whether the given feature is supported, and if provided, whether the
> given operation on the feature is supported.
>
> The first user of this ioctl is for setting the vfio-pci VF token,
> where the user provides a shared secret key (UUID) on a SR-IOV PF
> device, which users must provide when opening associated VF devices.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/pci/vfio_pci.c | 52
> +++
> include/uapi/linux/vfio.h | 37 +++
> 2 files changed, 89 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 8dd6ef9543ca..e4d5d26e5e71 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -1180,6 +1180,58 @@ static long vfio_pci_ioctl(void *device_data,
>
> return vfio_pci_ioeventfd(vdev, ioeventfd.offset,
> ioeventfd.data, count, ioeventfd.fd);
> + } else if (cmd == VFIO_DEVICE_FEATURE) {
> + struct vfio_device_feature feature;
> + uuid_t uuid;
> +
> + minsz = offsetofend(struct vfio_device_feature, flags);
> +
> + if (copy_from_user(&feature, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (feature.argsz < minsz)
> + return -EINVAL;
> +
> + if (feature.flags & ~(VFIO_DEVICE_FEATURE_MASK |
> + VFIO_DEVICE_FEATURE_SET |
> + VFIO_DEVICE_FEATURE_GET |
> + VFIO_DEVICE_FEATURE_PROBE))
> + return -EINVAL;
GET|SET|PROBE is well-defined, but what about GET|SET without PROBE? Do
we want to fence this in the generic ioctl handler part? Or is there
any sane way to implement that (read and then write back something?)
> +
> + switch (feature.flags & VFIO_DEVICE_FEATURE_MASK) {
> + case VFIO_DEVICE_FEATURE_PCI_VF_TOKEN:
> + if (!vdev->vf_token)
> + return -ENOTTY;
> +
> + /*
> + * We do not support GET of the VF Token UUID as this
> + * could expose the token of the previous device user.
> + */
> + if (feature.flags & VFIO_DEVICE_FEATURE_GET)
> + return -EINVAL;
> +
> + if (feature.flags & VFIO_DEVICE_FEATURE_PROBE)
> + return 0;
> +
> + /* Don't SET unless told to do so */
> + if (!(feature.flags & VFIO_DEVICE_FEATURE_SET))
> + return -EINVAL;
> +
> + if (feature.argsz < minsz + sizeof(uuid))
> + return -EINVAL;
> +
> + if (copy_from_user(&uuid, (void __user *)(arg + minsz),
> +sizeof(uuid)))
> + return -EFAULT;
> +
> + mutex_lock(&vdev->vf_token->lock);
> + uuid_copy(&vdev->vf_token->uuid, &uuid);
> + mutex_unlock(&vdev->vf_token->lock);
> +
> + return 0;
> + default:
> + return -ENOTTY;
> + }
> }
>
> return -ENOTTY;
(...)
Re: [dpdk-dev] net/netvsc: subchannel configuration failed due to unexpected NVS response
On Thu, 27 Feb 2020 11:16:01 -0500
Min Tang wrote:
> Hi Stephen:
>
> I saw the following error messages when using DPDK 18.11.2 in Azure:
>
> hn_nvs_execute(): unexpected NVS resp 0x6b, expect 0x85
> hn_dev_configure(): subchannel configuration failed
>
> It was not easy to reproduce it and it only occurred with multiple queues
> enabled. In hn_nvs_execute it expects the response to match the request. In
> the failed case, it was expecting NVS_TYPE_SUBCH_REQ (133 or 0x85) but
> got NVS_TYPE_RNDIS(107 or 0x6b). Obviously somewhere the NVS_TYPE_RNDIS
> message had been sent before the NVS_TYPE_SUBCH_REQ message was sent. I
> looked at the code and found that the NVS_TYPE_RNDIS message needs
> completion response but it does not receive the response message anywhere.
> The fix would be receiving and discarding the wrong response message(s).
>
> I put the following patches and it has fixed the problem.
>
> --- a/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:08:29.755530969 -0500
> +++ b/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:07:21.567371798 -0500
> @@ -92,7 +92,7 @@
> if (hdr->type != type) {
> PMD_DRV_LOG(ERR, "unexpected NVS resp %#x, expect %#x",
> hdr->type, type);
> - goto retry;
> + return -EINVAL;
> }
>
> if (len < resplen) {
Thanks for the analysis. Not sure if this the right fix.
Looks like the control channel needs additional locking.
Having two outstanding requests at once is not going to work well.
Re: [dpdk-dev] [PATCH v1 1/2] doc/failsafe: improve fail-safe documentation
On 2/22/2020 12:14 AM, Gaetan Rivet wrote: > Reading the fail-safe doc with a few years added, a few phrasing > choices are ambiguous or confusing. > > Signed-off-by: Gaetan Rivet cc'ed Marco & John for documentation (structure & language) perspective review.
Re: [dpdk-dev] [PATCH] af_packet: allow configuring number of rings
On Thu, 27 Feb 2020 17:20:45 + Ferruh Yigit wrote: > On 2/24/2020 11:11 PM, Stephen Hemminger wrote: > > The maximum number of rings in af_packet is hard coded as 16. > > The user should be able to configure this as part of DPDK config. > > > > Signed-off-by: Stephen Hemminger > > --- > > config/common_base| 1 + > > drivers/net/af_packet/rte_eth_af_packet.c | 3 +++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/config/common_base b/config/common_base > > index 6ea9c63cc36b..dd154a474b57 100644 > > --- a/config/common_base > > +++ b/config/common_base > > @@ -468,6 +468,7 @@ CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n > > # Compile software PMD backed by AF_PACKET sockets (Linux only) > > # > > CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n > > +CONFIG_RTE_PMD_AF_PACKET_MAX_RINGS=16 > > > > Not sure about adding a new config option for this. > > There is already "qpairs" devarg, allocating queues dynamically, instead of > using a per-defined sized arrays, should enable removing > 'RTE_PMD_AF_PACKET_MAX_RINGS' completely. But the current driver does not allow qpairs > 16. This is a config option to allow more.
Re: [dpdk-dev] [PATCH] af_packet: allow configuring number of rings
On 2/27/2020 5:51 PM, Stephen Hemminger wrote: > On Thu, 27 Feb 2020 17:20:45 + > Ferruh Yigit wrote: > >> On 2/24/2020 11:11 PM, Stephen Hemminger wrote: >>> The maximum number of rings in af_packet is hard coded as 16. >>> The user should be able to configure this as part of DPDK config. >>> >>> Signed-off-by: Stephen Hemminger >>> --- >>> config/common_base| 1 + >>> drivers/net/af_packet/rte_eth_af_packet.c | 3 +++ >>> 2 files changed, 4 insertions(+) >>> >>> diff --git a/config/common_base b/config/common_base >>> index 6ea9c63cc36b..dd154a474b57 100644 >>> --- a/config/common_base >>> +++ b/config/common_base >>> @@ -468,6 +468,7 @@ CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n >>> # Compile software PMD backed by AF_PACKET sockets (Linux only) >>> # >>> CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n >>> +CONFIG_RTE_PMD_AF_PACKET_MAX_RINGS=16 >>> >> >> Not sure about adding a new config option for this. >> >> There is already "qpairs" devarg, allocating queues dynamically, instead of >> using a per-defined sized arrays, should enable removing >> 'RTE_PMD_AF_PACKET_MAX_RINGS' completely. > > But the current driver does not allow qpairs > 16. > This is a config option to allow more. > This can be done without config option by removing 16 limitation.
Re: [dpdk-dev] net/netvsc: subchannel configuration failed due to unexpected NVS response
That quick fix was just to verify my guess. I agree that it needs more
comprehensive fix.
Yes, race condition is another issue here. In addition to that, I think in
the function that sends the NVS_TYPE_RNDIS message, it needs to drain the
response message.
I looked at the netvsc driver in Linux kernel, it receives all the VMBus
messages anachronously in another thread. That's probably something we can
think about in the DPDK driver.
On Thu, Feb 27, 2020 at 12:47 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> On Thu, 27 Feb 2020 11:16:01 -0500
> Min Tang wrote:
>
> > Hi Stephen:
> >
> > I saw the following error messages when using DPDK 18.11.2 in Azure:
> >
> > hn_nvs_execute(): unexpected NVS resp 0x6b, expect 0x85
> > hn_dev_configure(): subchannel configuration failed
> >
> > It was not easy to reproduce it and it only occurred with multiple queues
> > enabled. In hn_nvs_execute it expects the response to match the request.
> In
> > the failed case, it was expecting NVS_TYPE_SUBCH_REQ (133 or 0x85) but
> > got NVS_TYPE_RNDIS(107 or 0x6b). Obviously somewhere the NVS_TYPE_RNDIS
> > message had been sent before the NVS_TYPE_SUBCH_REQ message was sent. I
> > looked at the code and found that the NVS_TYPE_RNDIS message needs
> > completion response but it does not receive the response message
> anywhere.
> > The fix would be receiving and discarding the wrong response message(s).
> >
> > I put the following patches and it has fixed the problem.
> >
> > --- a/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:08:29.755530969 -0500
> > +++ b/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:07:21.567371798 -0500
> > @@ -92,7 +92,7 @@
> > if (hdr->type != type) {
> > PMD_DRV_LOG(ERR, "unexpected NVS resp %#x, expect %#x",
> > hdr->type, type);
> > - goto retry;
> > + return -EINVAL;
> > }
> >
> > if (len < resplen) {
>
> Thanks for the analysis. Not sure if this the right fix.
> Looks like the control channel needs additional locking.
> Having two outstanding requests at once is not going to work well.
>
[dpdk-dev] [PATCH v2] net/af_packet: remove limitation on number of qpairs
Since qpairs is part of the vdev arguments, there is no need to
limit it to 16. The queue arrays can be dynamically sized based
on the requested parameters.
Signed-off-by: Stephen Hemminger
---
drivers/net/af_packet/rte_eth_af_packet.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index f5806bf42c46..e5e0aa9277a8 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -37,8 +37,6 @@
#define DFLT_FRAME_SIZE(1 << 11)
#define DFLT_FRAME_COUNT (1 << 9)
-#define RTE_PMD_AF_PACKET_MAX_RINGS 16
-
struct pkt_rx_queue {
int sockfd;
@@ -77,8 +75,8 @@ struct pmd_internals {
struct tpacket_req req;
- struct pkt_rx_queue rx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
- struct pkt_tx_queue tx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
+ struct pkt_rx_queue *rx_queue;
+ struct pkt_tx_queue *tx_queue;
};
static const char *valid_arguments[] = {
@@ -601,6 +599,18 @@ rte_pmd_init_internals(struct rte_vdev_device *dev,
if (*internals == NULL)
return -1;
+
+ (*internals)->rx_queue = rte_calloc_socket("af_packet_rx",
+ nb_queues,
+ sizeof(struct pkt_rx_queue),
+ 0, numa_node);
+ (*internals)->tx_queue = rte_calloc_socket("af_packet_tx",
+ nb_queues,
+ sizeof(struct pkt_tx_queue),
+ 0, numa_node);
+ if (!(*internals)->rx_queue || !(*internals)->tx_queue)
+ return -1;
+
for (q = 0; q < nb_queues; q++) {
(*internals)->rx_queue[q].map = MAP_FAILED;
(*internals)->tx_queue[q].map = MAP_FAILED;
@@ -846,8 +856,7 @@ rte_eth_from_packet(struct rte_vdev_device *dev,
pair = &kvlist->pairs[k_idx];
if (strstr(pair->key, ETH_AF_PACKET_NUM_Q_ARG) != NULL) {
qpairs = atoi(pair->value);
- if (qpairs < 1 ||
- qpairs > RTE_PMD_AF_PACKET_MAX_RINGS) {
+ if (qpairs < 1) {
PMD_LOG(ERR,
"%s: invalid qpairs value",
name);
@@ -1019,6 +1028,8 @@ rte_pmd_af_packet_remove(struct rte_vdev_device *dev)
rte_free(internals->tx_queue[q].rd);
}
free(internals->if_name);
+ rte_free(internals->rx_queue);
+ rte_free(internals->tx_queue);
rte_eth_dev_release_port(eth_dev);
--
2.20.1
Re: [dpdk-dev] [PATCH v2] net/af_packet: remove limitation on number of qpairs
On Thu, Feb 27, 2020 at 12:00:03PM -0800, Stephen Hemminger wrote:
> Since qpairs is part of the vdev arguments, there is no need to
> limit it to 16. The queue arrays can be dynamically sized based
> on the requested parameters.
>
> Signed-off-by: Stephen Hemminger
LGTM!
Acked-by: John W. Linville
> ---
> drivers/net/af_packet/rte_eth_af_packet.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
> b/drivers/net/af_packet/rte_eth_af_packet.c
> index f5806bf42c46..e5e0aa9277a8 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -37,8 +37,6 @@
> #define DFLT_FRAME_SIZE (1 << 11)
> #define DFLT_FRAME_COUNT (1 << 9)
>
> -#define RTE_PMD_AF_PACKET_MAX_RINGS 16
> -
> struct pkt_rx_queue {
> int sockfd;
>
> @@ -77,8 +75,8 @@ struct pmd_internals {
>
> struct tpacket_req req;
>
> - struct pkt_rx_queue rx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
> - struct pkt_tx_queue tx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
> + struct pkt_rx_queue *rx_queue;
> + struct pkt_tx_queue *tx_queue;
> };
>
> static const char *valid_arguments[] = {
> @@ -601,6 +599,18 @@ rte_pmd_init_internals(struct rte_vdev_device *dev,
> if (*internals == NULL)
> return -1;
>
> +
> + (*internals)->rx_queue = rte_calloc_socket("af_packet_rx",
> + nb_queues,
> + sizeof(struct pkt_rx_queue),
> + 0, numa_node);
> + (*internals)->tx_queue = rte_calloc_socket("af_packet_tx",
> + nb_queues,
> + sizeof(struct pkt_tx_queue),
> + 0, numa_node);
> + if (!(*internals)->rx_queue || !(*internals)->tx_queue)
> + return -1;
> +
> for (q = 0; q < nb_queues; q++) {
> (*internals)->rx_queue[q].map = MAP_FAILED;
> (*internals)->tx_queue[q].map = MAP_FAILED;
> @@ -846,8 +856,7 @@ rte_eth_from_packet(struct rte_vdev_device *dev,
> pair = &kvlist->pairs[k_idx];
> if (strstr(pair->key, ETH_AF_PACKET_NUM_Q_ARG) != NULL) {
> qpairs = atoi(pair->value);
> - if (qpairs < 1 ||
> - qpairs > RTE_PMD_AF_PACKET_MAX_RINGS) {
> + if (qpairs < 1) {
> PMD_LOG(ERR,
> "%s: invalid qpairs value",
> name);
> @@ -1019,6 +1028,8 @@ rte_pmd_af_packet_remove(struct rte_vdev_device *dev)
> rte_free(internals->tx_queue[q].rd);
> }
> free(internals->if_name);
> + rte_free(internals->rx_queue);
> + rte_free(internals->tx_queue);
>
> rte_eth_dev_release_port(eth_dev);
>
> --
> 2.20.1
>
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
[dpdk-dev] [Bug 414] mlx5: test/debug_autotest failed when enable CONFIG_RTE_LIBRTE_MLX5_PMD=y
https://bugs.dpdk.org/show_bug.cgi?id=414
Bug ID: 414
Summary: mlx5: test/debug_autotest failed when enable
CONFIG_RTE_LIBRTE_MLX5_PMD=y
Product: DPDK
Version: 20.02
Hardware: POWER
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: thin...@linux.vnet.ibm.com
Target Milestone: ---
Compiled DPDK on powerpc with CONFIG_RTE_LIBRTE_MLX5_PMD=y
the test/debug_autotest failed
#./ppc_64-power8-linuxapp-gcc/app/test -n 4 -c f
RTE>>debug_autotest
1: [./ppc_64-power8-linuxapp-gcc/app/test(rte_dump_stack+0x38) [0xfabdbccaf08]]
Child process terminated as expected - Test passed!
test_exit_valChild process status: 139 and WIFEXITED = 0
Child process terminated with RC = 0
EAL: Error - exiting with code: 1
Cause: test_exit_valChild process status: 139 and WIFEXITED = 0
Child process terminated with RC = 0
Child process terminated with incorrect status (expected = 1)!
Test Failed
Child process exited with SIGSEGV 11
dmesg reported
[ 1014.235043] test[121837]: unhandled signal 11 at 0a1d55db62d0 nip
0a1d06b3c4c0 lr 0a1d06e9a8c8 code 1
when CONFIG_RTE_LIBRTE_MLX5_PMD=n
Test passed as expected
1: [./ppc_64-power8-linuxapp-gcc/app/test(rte_dump_stack+0x38) [0x7f845542528]]
Child process terminated as expected - Test passed!
test_exit_valChild process status: 0 and WIFEXITED = 1
EAL: Error - exiting with code: 1
Cause: test_exit_valChild process status: 256 and WIFEXITED = 1
EAL: Error - exiting with code: 2
Cause: test_exit_valChild process status: 512 and WIFEXITED = 1
EAL: Error - exiting with code: 255
Cause: test_exit_valChild process status: 65280 and WIFEXITED = 1
EAL: Error - exiting with code: -1
Cause: test_exit_valChild process status: 65280 and WIFEXITED = 1
test_exit Passed
Test OK
RTE>>quit
modified test_debug.c with some printf()
67 wait(&status);
68 printf("Child process status: %d and WIFEXITED = %d \n",
status,WIFEXITED(status));
69 #ifndef RTE_EAL_ALWAYS_PANIC_ON_ERROR
70 /*if(!WIFEXITED(status) || WEXITSTATUS(status) !=
(uint8_t)exit_val){ */
71 if(!WIFEXITED(status)) {
72 printf("Child process terminated with RC = %d\n",
WEXITSTATUS(status));
73 if ( WEXITSTATUS(status) != (uint8_t)exit_val) {
74 printf("Child process terminated with incorrect
status (expected = %d)!\n",
75 exit_val);
76 return -1;
77 }
78 }
79 #endif
I just found this in DPDK 20.02, will verify with other DPDK version.
OS: Linux ltc17u31 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:24 UTC
2020 ppc64le ppc64le ppc64le GNU/Linux
System: power9
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [PATCH] drivers/crypto: fix build with make
In the check for the version of intel-ipsec-mb library,
there is a backslash in front of the #include.
It is not clear why this backslash is for.
It is not clear why there was no error so far.
In an up-to-date ArchLinux, these errors were seen:
syntax error near unexpected token `|'
`grep -e "IMB_VERSION_STR" \#include | cut -d'"' -f2'
syntax error near unexpected token `|'
`grep -e "IMB_VERSION_NUM" \#include | cut -d' ' -f3'
The makefiles are fixed by removing the backslash.
Fixes: 3067c8ce77ac ("crypto/aesni_mb: fix build with custom dependency path")
Fixes: 457b8e372975 ("crypto/aesni_gcm: check dependency version with make")
Fixes: bf6eb2c22fd1 ("crypto/kasumi: use IPsec library")
Fixes: 7c87e2d7b359 ("crypto/snow3g: use IPsec library")
Fixes: 61f7c988e39e ("crypto/zuc: use IPsec library")
Cc: sta...@dpdk.org
Signed-off-by: Thomas Monjalon
---
drivers/crypto/aesni_gcm/Makefile | 2 +-
drivers/crypto/aesni_mb/Makefile | 2 +-
drivers/crypto/kasumi/Makefile| 2 +-
drivers/crypto/snow3g/Makefile| 2 +-
drivers/crypto/zuc/Makefile | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/aesni_gcm/Makefile
b/drivers/crypto/aesni_gcm/Makefile
index d8190a2ff4..e80a416261 100644
--- a/drivers/crypto/aesni_gcm/Makefile
+++ b/drivers/crypto/aesni_gcm/Makefile
@@ -20,7 +20,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
LDLIBS += -lrte_bus_vdev
-IMB_HDR = $(shell echo '\#include ' | \
+IMB_HDR = $(shell echo '#include ' | \
$(CC) -E $(EXTRA_CFLAGS) - | grep 'intel-ipsec-mb.h' | \
head -n1 | cut -d'"' -f2)
diff --git a/drivers/crypto/aesni_mb/Makefile b/drivers/crypto/aesni_mb/Makefile
index f1530e74c4..d81e5671df 100644
--- a/drivers/crypto/aesni_mb/Makefile
+++ b/drivers/crypto/aesni_mb/Makefile
@@ -20,7 +20,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
LDLIBS += -lrte_bus_vdev
-IMB_HDR = $(shell echo '\#include ' | \
+IMB_HDR = $(shell echo '#include ' | \
$(CC) -E $(EXTRA_CFLAGS) - | grep 'intel-ipsec-mb.h' | \
head -n1 | cut -d'"' -f2)
diff --git a/drivers/crypto/kasumi/Makefile b/drivers/crypto/kasumi/Makefile
index c94d6bdcf9..5b71481784 100644
--- a/drivers/crypto/kasumi/Makefile
+++ b/drivers/crypto/kasumi/Makefile
@@ -20,7 +20,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
LDLIBS += -lrte_bus_vdev
-IMB_HDR = $(shell echo '\#include ' | \
+IMB_HDR = $(shell echo '#include ' | \
$(CC) -E $(EXTRA_CFLAGS) - | grep 'intel-ipsec-mb.h' | \
head -n1 | cut -d'"' -f2)
diff --git a/drivers/crypto/snow3g/Makefile b/drivers/crypto/snow3g/Makefile
index 438119c3d5..b3807e4314 100644
--- a/drivers/crypto/snow3g/Makefile
+++ b/drivers/crypto/snow3g/Makefile
@@ -20,7 +20,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
LDLIBS += -lrte_bus_vdev
-IMB_HDR = $(shell echo '\#include ' | \
+IMB_HDR = $(shell echo '#include ' | \
$(CC) -E $(EXTRA_CFLAGS) - | grep 'intel-ipsec-mb.h' | \
head -n1 | cut -d'"' -f2)
diff --git a/drivers/crypto/zuc/Makefile b/drivers/crypto/zuc/Makefile
index b50883b2a7..ae0e1a2c2a 100644
--- a/drivers/crypto/zuc/Makefile
+++ b/drivers/crypto/zuc/Makefile
@@ -20,7 +20,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
LDLIBS += -lrte_bus_vdev
-IMB_HDR = $(shell echo '\#include ' | \
+IMB_HDR = $(shell echo '#include ' | \
$(CC) -E $(EXTRA_CFLAGS) - | grep 'intel-ipsec-mb.h' | \
head -n1 | cut -d'"' -f2)
--
2.25.1
Re: [dpdk-dev] [RFC 0/6] New sync modes for ring
On Tue, Feb 25, 2020 at 7:11 PM Ananyev, Konstantin wrote: We do have a run-time check in our current enqueue()/dequeue implementation. In fact we support both modes: we have generic rte_ring_enqueue(/dequeue)_bulk(/burst) where sync behaviour is determined at runtime by value of prod(/cons).single. Or user can call rte_ring_(mp/sp)_enqueue_* functions directly. This RFC follows exactly the same paradigm: rte_ring_enqueue(/dequeue)_bulk(/burst) kept generic and it's behaviour is determined at runtime, by value of prod(/cons).sync_type. Or user can call enqueue/dequeue with particular sync mode directly: rte_ring_(mp/sp/rts/hts)_enqueue_(bulk/burst)*. The only thing that changed: Format of prod/cons now could differ depending on mode selected at _init_. So you can't create a ring for let say SP mode and then in the middle of data-path change your mind and start using MP_RTS mode. For existing modes (SP/MP, SC/MC) format remains the same and user can still use them interchangeably, though of course that is an error prone practice. Makes sense. But I agree with the problem statement that in the virtualization use case, It may be possible to have N virtual cores runs on a physical core. IMO, The best solution would be keeping the ring API same and have a different flavor in "compile-time". Something like liburcu did for accommodating different flavors. i.e urcu-qsbr.h and urcu-bp.h will identical definition of API. The application can simply include ONE header file in a C file based on the flavor. I don't think it is a flexible enough approach. In one app user might need to have several rings with different sync modes. Or even user might need a ring with different sync modes for enqueue/dequeue. Ack. Yes, hiding rte_ring implementation inside .c would help a lot in terms of ABI maintenance and would make our future life easier. The question is what is the price for it in terms of performance, and are we ready to pay it. Not to mention that it would cause changes in many other libs/apps... So I think it should be a subject for a separate discussion. But, agree it would be good at least to measure the performance impact of such change. If I'll have some spare cycles, will give it a try. Meanwhile, can I ask Jerin and other guys to repeat tests from this RFC on their HW? Before continuing discussion would probably be good to know does the suggested patch work as expected across different platforms. I tested on an arm64 HW. The former section is without the patch(20.02) and later one with this patch. I agree with Konstantin that getting more platform tests will be good early so that we can focus on the approach to avoid back and forth latter. RTE>>ring_perf_autotest // without path ### Testing single element enq/deq ### legacy APIs: SP/SC: single: 289.78 legacy APIs: MP/MC: single: 516.20 ### Testing burst enq/deq ### legacy APIs: SP/SC: burst (size: 8): 312.88 legacy APIs: SP/SC: burst (size: 32): 426.72 legacy APIs: MP/MC: burst (size: 8): 510.95 legacy APIs: MP/MC: burst (size: 32): 702.01 ### Testing bulk enq/deq ### legacy APIs: SP/SC: bulk (size: 8): 306.74 legacy APIs: SP/SC: bulk (size: 32): 411.56 legacy APIs: MP/MC: bulk (size: 8): 501.32 legacy APIs: MP/MC: bulk (size: 32): 693.07 ### Testing empty bulk deq ### legacy APIs: SP/SC: bulk (size: 8): 7.00 legacy APIs: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### legacy APIs: SP/SC: bulk (size: 8): 74.36 legacy APIs: MP/MC: bulk (size: 8): 110.18 legacy APIs: SP/SC: bulk (size: 32): 23.04 legacy APIs: MP/MC: bulk (size: 32): 32.29 ### Testing using all slave nodes ## Bulk enq/dequeue count on size 8 Core [8] count = 293741 Core [9] count = 293741 Total count (size: 8): 587482 Bulk enq/dequeue count on size 32 Core [8] count = 244909 Core [9] count = 244909 Total count (size: 32): 1077300 ### Testing single element enq/deq ### elem APIs: element size 16B: SP/SC: single: 255.37 elem APIs: element size 16B: MP/MC: single: 456.68 ### Testing burst enq/deq ### elem APIs: element size 16B: SP/SC: burst (size: 8): 291.99 elem APIs: element size 16B: SP/SC: burst (size: 32): 456.25 elem APIs: element size 16B: MP/MC: burst (size: 8): 497.77 elem APIs: element size 16B: MP/MC: burst (size: 32): 680.87 ### Testing bulk enq/deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 284.40 elem APIs: element size 16B: SP/SC: bulk (size: 32): 453.17 elem APIs: element size 16B: MP/MC: bulk (size: 8): 485.77 elem APIs: element size 16B: MP/MC: bulk (size: 32): 675.08 ### Testing empty bulk deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 8.00 elem APIs: element size 16B: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 74.45 elem APIs: element size 16B: MP/MC: bulk (size: 8): 105.91 elem APIs: element size 16B: SP/SC: bulk (size: 32): 22.92 elem APIs: element size 16B: MP/MC: bulk (size: 32): 31.55 ### Testing usin
Re: [dpdk-dev] [RFC 1/1] lib/ring: add scatter gather and serial dequeue APIs
>
>
> Hi Honnappa,
Thanks Konstantin for the comments.
>
> > Add scatter gather APIs to avoid intermediate memcpy. Serial dequeue
> > APIs are added to support access to ring elements before actual
> > dequeue.
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > Reviewed-by: Ola Liljedahl
> > ---
> > lib/librte_ring/Makefile | 1 +
> > lib/librte_ring/meson.build| 1 +
> > lib/librte_ring/rte_ring_c11_mem.h | 98 +++
> > lib/librte_ring/rte_ring_elem_sg.h | 417 +
> > lib/librte_ring/rte_ring_generic.h | 93 +++
> > 5 files changed, 610 insertions(+)
>
> As was already noticed by you this patch overlaps quite a bit with another
> one:
> http://patches.dpdk.org/patch/66006/
I took a cursory look at this. I need to take a detailed look, plan to do so
soon.
>
> Though it seems there are few significant differences in our approaches (both
> API and implementation).
> So we probably need to come-up with some common view first, before
> moving forward with some unified version.
> To start a discussion, I produced some comments, pls see below.
>
> I don't see changes in rte_ring.h itself, but I suppose that's just because
> it is an
> RFC and it would be added in later versions?
I did not plan to add them. IMO, we should not add new APIs to that list. We
should encourage using the rte_ring_xxx_elem APIs should be used going forward.
They are interoperable (I mean, the application can call a mix of APIs)
> Another similar question there seems only _bulk_ (RTE_RING_QUEUE_FIXED)
> mode, I suppose _burst_ will also be added in later versions?
Here, I was trying to avoid providing APIs without a clear need (_bulk_ is
enough for RCU for now). If you see the need, I can add them.
>
> > diff --git a/lib/librte_ring/rte_ring_elem_sg.h
> > b/lib/librte_ring/rte_ring_elem_sg.h
> > new file mode 100644
> > index 0..a73f4fbfe
> > --- /dev/null
> > +++ b/lib/librte_ring/rte_ring_elem_sg.h
> > @@ -0,0 +1,417 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + *
> > + * Copyright (c) 2020 Arm Limited
> > + * Copyright (c) 2010-2017 Intel Corporation
> > + * Copyright (c) 2007-2009 Kip Macy km...@freebsd.org
> > + * All rights reserved.
> > + * Derived from FreeBSD's bufring.h
> > + * Used as BSD-3 Licensed with permission from Kip Macy.
> > + */
> > +
> > +#ifndef _RTE_RING_ELEM_SG_H_
> > +#define _RTE_RING_ELEM_SG_H_
> > +
> > +/**
> > + * @file
> > + * RTE Ring with
> > + * 1) user defined element size
> > + * 2) scatter gather feature to copy objects to/from the ring
> > + * 3) ability to reserve, consume/discard elements in the ring */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "rte_ring.h"
> > +#include "rte_ring_elem.h"
> > +
> > +/* Between load and load. there might be cpu reorder in weak model
> > + * (powerpc/arm).
> > + * There are 2 choices for the users
> > + * 1.use rmb() memory barrier
> > + * 2.use one-direction load_acquire/store_release barrier,defined by
> > + * CONFIG_RTE_USE_C11_MEM_MODEL=y
> > + * It depends on performance test results.
> > + * By default, move common functions to rte_ring_generic.h */ #ifdef
> > +RTE_USE_C11_MEM_MODEL #include "rte_ring_c11_mem.h"
> > +#else
> > +#include "rte_ring_generic.h"
> > +#endif
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr_64(struct rte_ring *r, uint32_t head,
> > + uint32_t num, void **dst1, uint32_t *n1, void **dst2) {
> > + uint32_t idx = head & r->mask;
> > + uint64_t *ring = (uint64_t *)&r[1];
> > +
> > + *dst1 = ring + idx;
> > + *n1 = num;
> > +
> > + if (idx + num > r->size) {
> > + *n1 = num - (r->size - idx - 1);
> > + *dst2 = ring;
> > + }
> > +}
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr_128(struct rte_ring *r, uint32_t head,
> > + uint32_t num, void **dst1, uint32_t *n1, void **dst2) {
> > + uint32_t idx = head & r->mask;
> > + rte_int128_t *ring = (rte_int128_t *)&r[1];
> > +
> > + *dst1 = ring + idx;
> > + *n1 = num;
> > +
> > + if (idx + num > r->size) {
> > + *n1 = num - (r->size - idx - 1);
> > + *dst2 = ring;
> > + }
> > +}
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr(struct rte_ring *r, uint32_t head,
> > + uint32_t esize, uint32_t num, void **dst1, uint32_t *n1, void
> > +**dst2) {
> > + if (esize == 8)
> > + return __rte_ring_get_elem_addr_64(r, head,
> > + num, dst1, n1, dst2);
> > + else if (esize == 16)
> > + return __rte_ring_get_elem_addr_128(r, head,
> > + num, dst1, n1, dst2);
> > + else {
> > + uint32_t idx, scale, nr_i
Re: [dpdk-dev] [PATCH 1/2] net/bonding: fix MAC address when switching active port
Hi,Ferruh Yigit
On 2020/2/28 1:03, Ferruh Yigit wrote:
On 2/25/2020 9:29 AM, Wei Hu (Xavier) wrote:
From: "Wei Hu (Xavier)"
Currently, based on a active-backup bond device, when the link status of
the primary port changes from up to down, one slave port changes to the
primary port, but the new primary port's MAC address cannot change to the
bond device's MAC address. And we can't continue receive packets whose
destination MAC addresses are the same as the bond devices's MAC address.
The current bonding PMD driver call mac_address_slaves_update function to
modify the MAC address of all slaves devices: the primary port using bond
device's MAC address, and other slaves devices using the respective MAC
address. We found that one error using primary_port instead of
current_primary_port in mac_address_slaves_update function.
On the other hand, The current bonding PMD driver sets slave devices's MAC
address according to the variable named current_primary_port. The variable
named current_primary_port changes in the following scenario:
1. Add the slave devices to bond, the first slave port will be regardes as
the current_primary_port. If changing the order of adding the slave
devices, the value of the variable named current_primary_port will be
different.
2. The upper application specifies primary_port via calling the
rte_eth_bond_primary_set API function.
3. Delete the primary slave device.
4. The link status of the primary port changes from up to down.
We have tested the above 4 cases and found that there are problems that
the new primary port's MAC address didn't change to the bond device's MAC
address when running case 3 and 4. When current_primary_port changes, the
new primary port's MAC address should change at the same time. We also need
to call mac_address_slaves_update function to update MAC addresses in case
3 and 4.
For more details please refer to:
https://bugs.dpdk.org/show_bug.cgi?id=256
Bugzilla ID: 256
Fixes: 2efb58cbab6e ("bond: new link bonding library")
Cc: sta...@dpdk.org
Reported-by: Chunsong Feng
Signed-off-by: Chunsong Feng
Signed-off-by: Wei Hu (Xavier)
Please cc the maintainer on the patches. cc'ed Chas for this one.
I am using './devtools/get-maintainer.sh' script, once you set it up, it helps a
lot.
Thanks for your suggestion.
Regards
Xavier
[dpdk-dev] [PATCH] net/i40e: enable dst MAC address as FDIR input set
When OVS-DPDK is working as a pure L2 switch, Destination MAC match
offload with Mark+RSS action would help the performance speed up.
And FVL FDIR should support to change input set to be destination MAC.
When create a FDIR rule which pattern only has ether dst_mac like below:
flow create 0 ingress pattern eth dst is / end
actions mark id / rss / end
The following 11 pctypes of matched packets can Mark+RSS.
PCTYPE_NONF_IPV4_UDP
PCTYPE_NONF_IPV4_TCP
PCTYPE_NONF_IPV4_SCTP
PCTYPE_NONF_IPV4_OTHER
PCTYPE_FRAG_IPV4
PCTYPE_NONF_IPV6_UDP
PCTYPE_NONF_IPV6_TCP
PCTYPE_NONF_IPV6_SCTP
PCTYPE_NONF_IPV6_OTHER
PCTYPE_FRAG_IPV6
PCTYPE_L2_PAYLOAD
Signed-off-by: Lunyuan Cui
---
drivers/net/i40e/i40e_ethdev.c | 92 +++---
drivers/net/i40e/i40e_ethdev.h | 10 +-
drivers/net/i40e/i40e_fdir.c | 8 +-
drivers/net/i40e/i40e_flow.c | 213 +
4 files changed, 226 insertions(+), 97 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 9fbda1c34..bc5522d53 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -9337,15 +9337,16 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
*/
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
- I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
- I40E_INSET_IPV4_TTL,
+ I40E_INSET_DMAC | I40E_INSET_VLAN_OUTER |
+ I40E_INSET_VLAN_INNER | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
- I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
- I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ I40E_INSET_DMAC | I40E_INSET_VLAN_OUTER |
+ I40E_INSET_VLAN_INNER | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_TTL | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
@@ -9357,36 +9358,38 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
- I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
- I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ I40E_INSET_DMAC | I40E_INSET_VLAN_OUTER |
+ I40E_INSET_VLAN_INNER | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_TTL | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
- I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
- I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
- I40E_INSET_SCTP_VT,
+ I40E_INSET_DMAC | I40E_INSET_VLAN_OUTER |
+ I40E_INSET_VLAN_INNER | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_TTL | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
- I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
- I40E_INSET_IPV4_TTL,
+ I40E_INSET_DMAC | I40E_INSET_VLAN_OUTER |
+ I40E_INSET_VLAN_INNER | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
- I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
- I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
- I40E_INSET_IPV6_TC | I40E_INSET_IPV6_
[dpdk-dev] net/i40e: add promiscuous configure unsupported check
Return ENOTSUP error code when configuring i40evf promiscuous mode to
fix port start hang issue on platforms which are unsupported to configure
promiscuous mode.
Fixes: ddc7cb0d9453 ("net/i40e: re-program promiscuous mode on VF
interface")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Zhang
---
drivers/net/i40e/i40e_ethdev_vf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index c34f520..244397e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2191,6 +2191,8 @@ i40evf_dev_promiscuous_enable(struct rte_eth_dev *dev)
ret = i40evf_config_promisc(dev, 1, vf->promisc_multicast_enabled);
if (ret == 0)
vf->promisc_unicast_enabled = TRUE;
+ else if (ret == I40E_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -2206,6 +2208,8 @@ i40evf_dev_promiscuous_disable(struct rte_eth_dev *dev)
ret = i40evf_config_promisc(dev, 0, vf->promisc_multicast_enabled);
if (ret == 0)
vf->promisc_unicast_enabled = FALSE;
+ else if (ret == I40E_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -2221,6 +2225,8 @@ i40evf_dev_allmulticast_enable(struct rte_eth_dev *dev)
ret = i40evf_config_promisc(dev, vf->promisc_unicast_enabled, 1);
if (ret == 0)
vf->promisc_multicast_enabled = TRUE;
+ else if (ret == I40E_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -2236,6 +2242,8 @@ i40evf_dev_allmulticast_disable(struct rte_eth_dev *dev)
ret = i40evf_config_promisc(dev, vf->promisc_unicast_enabled, 0);
if (ret == 0)
vf->promisc_multicast_enabled = FALSE;
+ else if (ret == I40E_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
--
2.7.4
[dpdk-dev] [PATCH v2 0/2] no-huge test suite
For environments (such as containers) where hugetlbfs are not available, some unit tests can be run with 'no-huge' option. A suite is added. It includes cases that can run without hugetlbfs support. To avoid Travis CI job bloating, multiple test suites are allowed to run in one job. v2: Add a patch to enable running multiple suites in a job. (David) Ruifeng Wang (2): ci: allow multiple test suites to run in one job ci: add test suite run without hugepage .ci/linux-build.sh | 4 ++- .ci/linux-setup.sh | 16 ++ .travis.yml | 10 +-- app/test/meson.build | 71 4 files changed, 93 insertions(+), 8 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v2 1/2] ci: allow multiple test suites to run in one job
Run multiple test suites in a single Travis CI job helps to avoid
job bloating and save build time.
When RUN_TESTS is set, TEST_SUITES includes a list of suites that
need to run in the job, otherwise fast-tests is run by default.
Suggested-by: David Marchand
Signed-off-by: Ruifeng Wang
Reviewed-by: Gavin Hu
---
.ci/linux-build.sh | 4 +++-
.ci/linux-setup.sh | 16 +++-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d500c4c00..ddb925418 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -90,5 +90,7 @@ if [ "$ABI_CHECKS" = "1" ]; then
fi
if [ "$RUN_TESTS" = "1" ]; then
-sudo meson test -C build --suite fast-tests -t 3
+for testsuite in ${TEST_SUITES:-fast-tests}; do
+sudo meson test -C build --suite $testsuite -t 3
+done
fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index 2b07d1e0b..4c5ddeb96 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -3,10 +3,16 @@
# need to install as 'root' since some of the unit tests won't run without it
sudo python3 -m pip install --upgrade 'meson==0.47.1'
-# skip hugepage settings if tests will not run
+# set up hugepage if fast-tests suite (default) will run
if [ "$RUN_TESTS" = "1" ]; then
-# setup hugepages
-cat /proc/meminfo
-sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
-cat /proc/meminfo
+for testsuite in ${TEST_SUITES:-fast-tests}; do
+if [ "$testsuite" = "fast-tests" ]; then
+# setup hugepages
+cat /proc/meminfo
+sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
+cat /proc/meminfo
+
+break
+fi
+done
fi
--
2.17.1
[dpdk-dev] [PATCH v2 2/2] ci: add test suite run without hugepage
This test suite is derived from fast-tests suite. Cases in this
suite are run with '--no-huge' flag.
The suite aims to cover as many as possible test cases out of the
fast-tests suites in the environments without huge pages support,
like containers.
Signed-off-by: Ruifeng Wang
Reviewed-by: Gavin Hu
---
.travis.yml | 10 +--
app/test/meson.build | 71
2 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index b64a81bd0..eed1d96db 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -40,7 +40,7 @@ jobs:
- env: DEF_LIB="static"
arch: amd64
compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=1 TEST_SUITES="fast-tests nohuge-tests"
arch: amd64
compiler: gcc
- env: DEF_LIB="shared" BUILD_DOCS=1
@@ -63,7 +63,7 @@ jobs:
- env: DEF_LIB="static"
arch: amd64
compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=1 TEST_SUITES="fast-tests nohuge-tests"
arch: amd64
compiler: clang
- env: DEF_LIB="shared" BUILD_DOCS=1
@@ -101,6 +101,9 @@ jobs:
- env: DEF_LIB="static"
arch: arm64
compiler: gcc
+ - env: DEF_LIB="shared" RUN_TESTS=1 TEST_SUITES="nohuge-tests"
+arch: arm64
+compiler: gcc
- env: DEF_LIB="shared" BUILD_DOCS=1
arch: arm64
compiler: gcc
@@ -124,3 +127,6 @@ jobs:
- env: DEF_LIB="shared"
arch: arm64
compiler: clang
+ - env: DEF_LIB="shared" RUN_TESTS=1 TEST_SUITES="nohuge-tests"
+arch: arm64
+compiler: clang
diff --git a/app/test/meson.build b/app/test/meson.build
index 0a2ce710f..162a1a76f 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -237,6 +237,60 @@ fast_test_names = [
'thash_autotest',
]
+nohuge_test_names = [
+'byteorder_autotest',
+'cmdline_autotest',
+'common_autotest',
+'cpuflags_autotest',
+'cycles_autotest',
+'debug_autotest',
+'eal_flags_n_opt_autotest',
+'eal_flags_no_huge_autotest',
+'eal_flags_vdev_opt_autotest',
+'eal_fs_autotest',
+'errno_autotest',
+'event_ring_autotest',
+'fib_autotest',
+'fib6_autotest',
+'interrupt_autotest',
+'logs_autotest',
+'lpm_autotest',
+'lpm6_autotest',
+'memcpy_autotest',
+'meter_autotest',
+'per_lcore_autotest',
+'prefetch_autotest',
+'rcu_qsbr_autotest',
+'red_autotest',
+'rib_autotest',
+'rib6_autotest',
+'ring_autotest',
+'rwlock_rda_autotest',
+'rwlock_rds_wrm_autotest',
+'rwlock_rde_wro_autotest',
+'sched_autotest',
+'spinlock_autotest',
+'string_autotest',
+'tailq_autotest',
+'user_delay_us',
+'version_autotest',
+'crc_autotest',
+'delay_us_sleep_autotest',
+'eventdev_common_autotest',
+'fbarray_autotest',
+'ipsec_autotest',
+'kni_autotest',
+'kvargs_autotest',
+'member_autotest',
+'metrics_autotest',
+'power_cpufreq_autotest',
+'power_autotest',
+'power_kvm_vm_autotest',
+'reorder_autotest',
+'service_autotest',
+'thash_autotest',
+]
+
perf_test_names = [
'ring_perf_autotest',
'mempool_perf_autotest',
@@ -341,6 +395,10 @@ if dpdk_conf.has('RTE_LIBRTE_RING_PMD')
fast_test_names += 'latencystats_autotest'
driver_test_names += 'link_bonding_mode4_autotest'
fast_test_names += 'pdump_autotest'
+ nohuge_test_names += 'ring_pmd_autotest'
+ nohuge_test_names += 'bitratestats_autotest'
+ nohuge_test_names += 'latencystats_autotest'
+ nohuge_test_names += 'pdump_autotest'
endif
if dpdk_conf.has('RTE_LIBRTE_POWER')
@@ -430,6 +488,19 @@ foreach arg : fast_test_names
endif
endforeach
+foreach arg : nohuge_test_names
+ if host_machine.system() == 'linux'
+ test(arg, dpdk_test,
+ env : ['DPDK_TEST=' + arg],
+ args : test_args +
+['--no-huge'] + ['-m 1024'] +
+['--file-prefix=@0@'.format(arg)],
+ timeout : timeout_seconds_fast,
+ is_parallel : false,
+ suite : 'nohuge-tests')
+ endif
+endforeach
+
foreach arg : perf_test_names
test(arg, dpdk_test,
env : ['DPDK_TEST=' + arg],
--
2.17.1
[dpdk-dev] DSW eventdev bug?
Hi, This is concerning the DSW PMD for eventdev. In our application we put some debugs to see that the same ATOMIC flow isn't scheduled to 2 different cores. Strangely enough we hit it. Not sure if we are missing something OR it is a bug. We put some instrumentation code inside DSW and found the following: - Time T1: flow1 is on core1 - Time T2: core1 decides to migrate flow1 to core2 (using seen_events etc.) - Time T3: core1 completes migration of flow1 to core2 - Time T4: core3 sends flow1 pkts (PKT1) to core2 - Time T5: core1 wants to do another migration and again picks flow1!!! flow1 is owned by core2 at this time - Time T6-T7: core1 migrates flow1 to core4. core2 happily acknowledges core1's attempt to migrate flow1 since it just has to pause, unpause and flush while PKT1 is still in core2. There is no error check to see if someone else is migrating my flow :) - Time T8: core3 sends flow1 pkt (PKT2) -- this time to core4. Now we have the problem of PKT1 in core2 and PKT2 in core4 I think what went wrong was that core1 was using a stale seen_events which had the old stuff from previous migration. During dsw_port_end_migration we only reset seen_events_len but not seen_events_idx. So while the latest events (since the last migration) are towards the end to port->seen_events (since seen_events_idx is pointing there) all the candidate flow finding may end up looking from 0 - seen_events_len: thus using stale information from past migration. Pls confirm if the above findings are correct. I tried the following and seems to fix the problem. Pls let me know if this is the way to fix the issue: diff -up ./drivers/event/dsw/dsw_event.c.original ./drivers/event/dsw/dsw_event.c --- ./drivers/event/dsw/dsw_event.c.original 2019-09-05 16:39:52.662976000 -0700 +++ ./drivers/event/dsw/dsw_event.c 2020-02-27 14:49:14.320156000 -0800 @@ -627,6 +641,7 @@ dsw_port_end_migration(struct dsw_evdev port->migration_state = DSW_MIGRATION_STATE_IDLE; port->seen_events_len = 0; + port->seen_events_idx = 0; dsw_port_migration_stats(port); Thanks -Venky
[dpdk-dev] [RFC PATCH 0/5] virtio-net support for Windows draft
This patchset provides reference of the changes made to run virtio-net PMD with Windows draft DPDK, so that this could be reproduced. Is is not intended to be merged neither soon, nor "as is". Patches must be applied over "multi-BAR" patchset yet to be released by Microsoft, those patches are not included. After applying Microsoft patches, the whole drivers/net/virtio directory from upstream v18.08 must be imported. It is also not included for brevity. Dmitry Kozlyuk (5): pci/windows: add stubs for port IO net: add stub for RARP packet generation on Windows pci/windows: split config I/O into series of fixed-size operations netuio: change class for Net to custom mk/windows: add virtio-net PMD drivers/bus/pci/windows/pci.c | 80 +- drivers/net/virtio/virtio_ethdev.c| 4 + kernel/windows/netuio/netuio.inf | 17 +- lib/librte_eal/windows/eal/eal.c | 4 + lib/librte_net/rte_net.c | 12 + mk/exec-env/windows/dpdk.sln | 754 +- mk/exec-env/windows/l2fwd/l2fwd.vcxproj | 242 +++--- mk/exec-env/windows/l3fwd/l3fwd.vcxproj | 292 +++ .../librte_pmd_i40e.vcxproj.filters | 198 + .../librte_pmd_net_virtio.vcxproj | 129 +++ 10 files changed, 1075 insertions(+), 657 deletions(-) create mode 100644 mk/exec-env/windows/librte_pmd_net_virtio/librte_pmd_i40e.vcxproj.filters create mode 100644 mk/exec-env/windows/librte_pmd_net_virtio/librte_pmd_net_virtio.vcxproj -- 2.25.1
[dpdk-dev] [RFC PATCH 2/5] net: add stub for RARP packet generation on Windows
RARP packets are optionally generated by virtio-net PMD.
Signed-off-by: Dmitry Kozlyuk
---
lib/librte_net/rte_net.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/librte_net/rte_net.c b/lib/librte_net/rte_net.c
index 56a13e3c4..8391ceae7 100644
--- a/lib/librte_net/rte_net.c
+++ b/lib/librte_net/rte_net.c
@@ -487,3 +487,15 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
return pkt_type;
}
+
+#ifdef _WIN64
+struct rte_mbuf * __rte_experimental
+rte_net_make_rarp_packet(struct rte_mempool *mpool,
+ const struct ether_addr *mac)
+{
+ RTE_SET_USED(mpool);
+ RTE_SET_USED(mac);
+ RTE_LOG(ERR, EAL, "RARP packet creation not implemented for Windows\n");
+ return NULL;
+}
+#endif
--
2.25.1
[dpdk-dev] [RFC PATCH 3/5] pci/windows: split config I/O into series of fixed-size operations
PCI bus kernel driver mandates accessing config space in a series of
reads/writes by 4, 2, or 1 bytes. NETUIO driver checks this requirement
before performing config space I/O. Users of DPDK PCI bus driver,
however, access config space without regard for this requirement.
Make DPDK PCI bus driver split config I/O to a series of 4-, 2-,
or 1-byte reads/writes. Each of these operations is a syscall to netUIO.
Signed-off-by: Dmitry Kozlyuk
---
drivers/bus/pci/windows/pci.c | 45 ---
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index 387ed4f02..4ffa6a610 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -200,6 +200,32 @@ int send_ioctl(HANDLE f, DWORD ioctl,
return ERROR_SUCCESS;
}
+static int
+pci_config_io_sized(HANDLE device, struct dpdk_pci_config_io *io,
+ void **buf, size_t *left_size, size_t access_size)
+{
+ uint64_t out;
+
+ io->access_size = access_size;
+
+ while (*left_size >= access_size) {
+ if (io->op == PCI_IO_WRITE)
+ memcpy(&io->data, *buf, access_size);
+
+ if (send_ioctl(device, IOCTL_NETUIO_PCI_CONFIG_IO,
+ io, sizeof(*io), &out, sizeof(out)) !=
ERROR_SUCCESS)
+ return -1;
+
+ if (io->op == PCI_IO_READ)
+ memcpy(*buf, &out, access_size);
+
+ io->offset += access_size;
+ *buf += access_size;
+ *left_size -= access_size;
+ }
+ return 0;
+}
+
/* Send IOCTL to driver to read/write PCI configuration space */
static
int pci_config_io(const struct rte_pci_device *dev, void *buf,
@@ -227,23 +253,14 @@ int pci_config_io(const struct rte_pci_device *dev, void
*buf,
pci_io.dev_addr.dev_num = dev->addr.devid;
pci_io.dev_addr.func_num = dev->addr.function;
pci_io.offset = offset;
- pci_io.access_size = sizeof(UINT32);
pci_io.op = operation;
- if (operation == PCI_IO_WRITE)
- {
- pci_io.data.u32 = *(UINT32 UNALIGNED*)buf;
- }
-
- uint64_t outputbuf = 0;
- if (send_ioctl(f, IOCTL_NETUIO_PCI_CONFIG_IO, &pci_io, sizeof(pci_io),
- &outputbuf, sizeof(outputbuf)) != ERROR_SUCCESS)
+ if (pci_config_io_sized(f, &pci_io, &buf, &len, sizeof(uint32_t)) < 0)
+ goto error;
+ if (pci_config_io_sized(f, &pci_io, &buf, &len, sizeof(uint16_t)) < 0)
+ goto error;
+ if (pci_config_io_sized(f, &pci_io, &buf, &len, sizeof(uint8_t)) < 0)
goto error;
-
- if (operation == PCI_IO_READ)
- {
- memcpy(buf, &outputbuf, sizeof(UINT32));
- }
ret = 0;
error:
--
2.25.1
[dpdk-dev] [RFC PATCH 1/5] pci/windows: add stubs for port IO
NetUIO does not currently implement port I/O, which is used by some
drivers, notable virtio-net in legacy mode.
Signed-off-by: Dmitry Kozlyuk
---
drivers/bus/pci/windows/pci.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index 75168c542..387ed4f02 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -143,6 +143,38 @@ int rte_pci_write_config(const struct rte_pci_device *dev,
return pci_config_io(dev, (void *)buf, len, offset, PCI_IO_WRITE);
}
+int
+rte_pci_ioport_map(struct rte_pci_device *dev, int bar,
+ struct rte_pci_ioport *p)
+{
+ RTE_SET_USED(dev);
+ RTE_SET_USED(bar);
+ RTE_SET_USED(p);
+ RTE_LOG(ERR, EAL, "I/O port mapping not supported for Windows\n");
+ return -1;
+}
+
+void
+rte_pci_ioport_read(struct rte_pci_ioport *p,
+ void *data, size_t len, off_t offset)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(data);
+ RTE_SET_USED(len);
+ RTE_SET_USED(offset);
+ RTE_LOG(ERR, EAL, "I/O port read not implemented for Windows\n");
+}
+
+void
+rte_pci_ioport_write(struct rte_pci_ioport *p,
+ const void *data, size_t len, off_t offset)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(data);
+ RTE_SET_USED(len);
+ RTE_SET_USED(offset);
+ RTE_LOG(ERR, EAL, "I/O port write not implemented for Windows\n");
+}
static
int send_ioctl(HANDLE f, DWORD ioctl,
--
2.25.1
[dpdk-dev] [RFC PATCH 4/5] netuio: change class for Net to custom
This resolves the issue with timeout on driver loading.
Signed-off-by: Dmitry Kozlyuk
---
drivers/bus/pci/windows/pci.c| 3 ++-
kernel/windows/netuio/netuio.inf | 11 +--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index 4ffa6a610..de385bf89 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -731,7 +731,8 @@ rte_pci_scan(void)
SP_DEVINFO_DATA DeviceInfoData = { 0 };
int ret = -1;
- hDevInfo = SetupDiGetClassDevs(&GUID_DEVCLASS_NET, NULL, NULL,
DIGCF_PRESENT);
+ hDevInfo = SetupDiGetClassDevs(
+ NULL, L"PCI", NULL, DIGCF_ALLCLASSES | DIGCF_PRESENT);
if (INVALID_HANDLE_VALUE == hDevInfo) {
RTE_LOG(ERR, EAL, "Unable to enumerate PCI devices.\n",
__func__);
goto end;
diff --git a/kernel/windows/netuio/netuio.inf b/kernel/windows/netuio/netuio.inf
index 4c4d5e047..e244bed3a 100644
--- a/kernel/windows/netuio/netuio.inf
+++ b/kernel/windows/netuio/netuio.inf
@@ -36,12 +36,19 @@
[Version]
Signature="$WINDOWS NT$"
-Class=Net
-ClassGuid={4d36e972-e325-11ce-bfc1-08002be10318}
+Class=UIO
+ClassGuid={86807C09-8149-4C34-9F2D-82575B8369DA}
Provider=%Intel%
CatalogFile=netuio.cat
DriverVer=
+[ClassInstall32]
+Addreg=UioClassReg
+
+[UioClassReg]
+HKR,,,0,%ClassName%
+HKR,,Icon,,-5
+
;*
; Install Section
;*
--
2.25.1
[dpdk-dev] [RFC PATCH 5/5] mk/windows: add virtio-net PMD
Signed-off-by: Dmitry Kozlyuk
---
drivers/net/virtio/virtio_ethdev.c| 4 +
kernel/windows/netuio/netuio.inf | 6 +
lib/librte_eal/windows/eal/eal.c | 4 +
mk/exec-env/windows/dpdk.sln | 754 +-
mk/exec-env/windows/l2fwd/l2fwd.vcxproj | 242 +++---
mk/exec-env/windows/l3fwd/l3fwd.vcxproj | 292 +++
.../librte_pmd_i40e.vcxproj.filters | 198 +
.../librte_pmd_net_virtio.vcxproj | 129 +++
8 files changed, 989 insertions(+), 640 deletions(-)
create mode 100644
mk/exec-env/windows/librte_pmd_net_virtio/librte_pmd_i40e.vcxproj.filters
create mode 100644
mk/exec-env/windows/librte_pmd_net_virtio/librte_pmd_net_virtio.vcxproj
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 614357da7..aa951e351 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1786,6 +1786,7 @@ static struct rte_pci_driver rte_virtio_pmd = {
.remove = eth_virtio_pci_remove,
};
+#ifndef _WIN64
RTE_INIT(rte_virtio_pmd_init)
{
if (rte_eal_iopl_init() != 0) {
@@ -1795,6 +1796,9 @@ RTE_INIT(rte_virtio_pmd_init)
rte_pci_register(&rte_virtio_pmd);
}
+#endif
+
+RTE_PMD_REGISTER_PCI(net_virtio, rte_virtio_pmd);
static bool
rx_offload_enabled(struct virtio_hw *hw)
diff --git a/kernel/windows/netuio/netuio.inf b/kernel/windows/netuio/netuio.inf
index e244bed3a..89d7c183c 100644
--- a/kernel/windows/netuio/netuio.inf
+++ b/kernel/windows/netuio/netuio.inf
@@ -56,6 +56,7 @@ HKR,,Icon,,-5
[Manufacturer]
%Intel%=Standard,NT$ARCH$
%Broadcom%=Broadcom,NT$ARCH$
+%virtio%=virtio,NT$ARCH$
[Standard.NT$ARCH$]
%F1583.netuio.Description%=netuio_Device, PCI\VEN_8086&DEV_1583
@@ -67,6 +68,9 @@ HKR,,Icon,,-5
[Broadcom.NT$ARCH$]
%F16D7.netuio.Description%=netuio_Device, PCI\VEN_14E4&DEV_16D7
+[virtio.NT$ARCH$]
+%virtio.netuio.Description%=netuio_Device,
PCI\VEN_1AF4&DEV_1041&SUBSYS_11001AF4&REV_01
+
[netuio_Device.NT]
CopyFiles=Drivers_Dir
@@ -126,6 +130,7 @@ KmdfLibraryVersion = $KMDFVERSION$
SPSVCINST_ASSOCSERVICE= 0x0002
Intel = "Intel"
Broadcom = "Broadcom Corporation"
+virtio = "virtio"
ClassName = "Intel(R) DPDK netUIO Driver"
DiskName = "DPDK netUIO Installation Disk"
F1583.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Converged
Network Adapter XL710-Q2"
@@ -134,5 +139,6 @@ F158B.netuio.Description = "DPDK netUIO for Intel(R)
Ethernet Network Adapter XX
F37D0.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Connection X722"
F153B.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Connection
I217-V"
F16D7.netuio.Description = "DPDK netUIO for Broadcom P225p NetXtreme-E
Dual-port 10Gb/25Gb Ethernet PCIe Adapter"
+virtio.netuio.Description = "DPDK netUIO for virtio-net (modern)"
netuio.DeviceDesc = "netuio Device"
netuio.SVCDESC = "netuio Service"
diff --git a/lib/librte_eal/windows/eal/eal.c b/lib/librte_eal/windows/eal/eal.c
index 9c3e52e1f..0a35d46ef 100644
--- a/lib/librte_eal/windows/eal/eal.c
+++ b/lib/librte_eal/windows/eal/eal.c
@@ -80,11 +80,13 @@ extern void init_rte_lpm6_tailq(void);
/* these functions are created by the RTE_PMD_REGISTER_PCI macro */
extern void pciinitfn_net_i40e(void);
+extern void pciinitfn_net_virtio(void);
/* these are more constructor-like function, that we'll need to call at the
start */
extern void rte_timer_init(void);
extern void rte_log_init(void);
extern void i40e_init_log(void);
+extern void virtio_init_log(void);
/* Return a pointer to the configuration structure */
struct rte_config *
@@ -475,6 +477,7 @@ eal_register_and_init_pmd()
{
/* these functions are created by the RTE_PMD_REGISTER_PCI macro */
pciinitfn_net_i40e(); /* init the Intel 40GbE PMD */
+ pciinitfn_net_virtio(); /* init the virtio-net PMD */
}
/* Launch threads, called at application init(). */
@@ -516,6 +519,7 @@ rte_eal_init(int argc, char **argv)
rte_eal_log_init(NULL, 0);
rte_log_init();
i40e_init_log();
+ virtio_init_log();
eal_log_level_parse(argc, argv);
diff --git a/mk/exec-env/windows/dpdk.sln b/mk/exec-env/windows/dpdk.sln
index ed9197861..3abea0c41 100644
--- a/mk/exec-env/windows/dpdk.sln
+++ b/mk/exec-env/windows/dpdk.sln
@@ -1,373 +1,381 @@
-
-Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio 15
-VisualStudioVersion = 15.0.27130.2010
-MinimumVisualStudioVersion = 10.0.40219.1
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "librte_mempool",
"librte_mempool\librte_mempool.vcxproj",
"{EEDD0F26-9B2E-460E-9D8F-C3F3C0B999B7}"
- ProjectSection(ProjectDependencies) = postProject
- {60499A5F-031F-41E1-86DE-425A27AE9680} =
{60499A5F-031F-41E1-86DE-425A27AE9680}
- EndProjectSection
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "librte_ring",
"librte_ring\librte_ring.vcxproj", "{0746F0FF-F42C-4A
