Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice
On Mon, Dec 2, 2019 at 5:27 PM Andrew Rybchenko wrote: > > On 12/2/19 2:09 PM, Jerin Jacob wrote: > > On Mon, Dec 2, 2019 at 6:16 PM Thomas Monjalon wrote: > >> > >> 02/12/2019 05:21, Jerin Jacob: > >>> On Mon, Nov 25, 2019 at 8:39 PM Thomas Monjalon > >>> wrote: > > 25/11/2019 11:44, Jerin Jacob: > > On Sun, Nov 24, 2019 at 3:12 AM Thomas Monjalon > > wrote: > >> > >> 23/11/2019 10:42, Jerin Jacob: > >>> On Sat, Nov 23, 2019 at 3:58 AM Thomas Monjalon > >>> wrote: > 22/11/2019 12:53, Andrew Rybchenko: > > On 11/22/19 2:15 PM, Thomas Monjalon wrote: > >> 22/11/2019 11:12, Andrew Rybchenko: > >>> On 11/22/19 1:01 AM, Thomas Monjalon wrote: > 19/11/2019 13:12, Andrew Rybchenko: > > The deprecation notice is required since it adds more > > requirements > > when RTE flow mark and flag actions may be used and require > > changes in applications. > I am still not sure what is the best solution here. > I continued to think about it in this thread: > http://mails.dpdk.org/archives/dev/2019-November/151960.html > > I think we cannot require any application change until 20.11 > in order to keep API (and behaviour) compatibility. > >>> Expected, but still very disappointing. > >>> > >>> The feature is implemented by Pavan (@ Marvell), supported by me, > >>> used by Qi (@ Intel), looks better than alternatives from > >>> application > >>> developer point of view [1] and finally postponed for 1 year > >>> without really > >>> strong motivation. > >> > >> I see different valuable point of views. This is enough motivation. > > > > It looks like I miss it in previous discussion, I would be thankful > > if > > you give me links to read or hints how to find. > > http://mails.dpdk.org/archives/dev/2019-November/150793.html > > > Introducing new types of controls would make configuration more and > > more complex. I think that many different types of control would > > over-complicate it. May be it is unavoidable, but it should be clear > > why the problem cannot be solved using existing types of controls > > (e.g. offloads). > > The offload control is used as an effective configuration for now. > The features which are configured with DEV_RX_OFFLOAD_* > do not need any other API to be used. > Extending DEV_RX_OFFLOAD_* bits for enabling features which > must be configured via other API anyway, is possible. > The real problem is that features in DEV_RX_OFFLOAD_* are supposed > to be disabled by default. If we add some opt-in features here, > we cannot enable them by default for API compatibility and do the > right thing by default. > > Choosing DEV_RX_OFFLOAD_* bits or rte_eth_dev_opt* functions is a > detail. > The real decision is to change the API for using all these features. > Can we keep all features available by default (opt-out)? > >>> > >>> IMO, *rte_eth_dev_opt* has following problems > >>> > >>> 1) It is not multi-process friendly. If we are changing the Rx/Tx > >>> function pointer, based on > >>> the selected offload, then, using *rte_eth_dev_opt* scheme won't > >>> really work(if the new API > >>> called after the secondary process launch) > >> > >> Yes it must be used before launching the secondary process. > >> It is the same as DEV_RX_OFFLOAD_* config. > > > > Yes. rte_eth_dev_opt_* has another dimension to enable and disable as > > API. > > So, we need to document, opt-in -> start() -> opt-out case won't work > > in multi process > > case. > > > >> > >>> 2) If we are taking rte_eth_dev_opt path then by default feature has > >>> to be enabled to > >>> not break the functional ABI. That scheme won't scale if as when we > >>> keep adding the new features. > >>> It is always easy for the application to define "what it wants" vs > >>> "what it does not want" > >> > >> Yes, opt-in may look more natural than opt-out. > >> But opt-in makes the default more complex, and changes the API. > >> > >>> 3) Defining the device state after the reconfigure operation. > >>> > >>> IMO, if any operation is connected to fastpath it is better to use > >>> DEV_RX_OFFLOAD_ like > >>> this feature where enable or disable PMDs from updating > >>> ``rte_mbuf::hash::fdir`` so that if possible > >>> we can use different Rx function pointer if possible(Hence it can work > >>> with the multi-process case case) > >> > >> I reply to 2 and 3 together. > >> > >>
Re: [dpdk-dev] [PATCH] test/common: fix log2 check
On Wed, Dec 4, 2019 at 10:20 PM Aaron Conole wrote:
>
> David Marchand writes:
>
> > We recently started to get random failures on the common_autotest ut with
> > clang on Ubuntu 16.04.6.
> >
> > Example: https://travis-ci.com/DPDK/dpdk/jobs/263177424
> >
> > Wrong rte_log2_u64(0) val 0, expected
> > Test Failed
> >
> > The ut passes 0 to log2() to get an expected value.
> >
> > Quoting log2 / log(3) manual:
> > If x is zero, then a pole error occurs, and the functions return
> > -HUGE_VAL, -HUGE_VALF, or -HUGE_VALL, respectively.
> >
> > rte_log2_uXX helpers handle 0 as a special value and return 0.
> > Let's have dedicated tests for this case.
> >
> > Fixes: 05c4345ef5c2 ("test: add unit test for integer log2 function")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
> > ---
>
> Acked-by: Aaron Conole
>
> Somethings that concern me:
>
> 1. A log2(0) should probably be an undetermined value, but this
> effectively makes log2(0) == log2(1) so that if anyone uses these
> for some mathematical work, it will have an exceptional behavior. I
> know it's documented from a programmer perspective, but I am all for
> documenting the mathematical side effect as well.
What do you have in mind, adding a big warning in the doxygen "THIS IS
NOT REAL MATH STUFF" ? :-)
>
> 2. Why hasn't this been complaining for so long? Or has it and we just
> haven't noticed? Were some compiler flags changed recently? (maybe
> -funsafe-math was always set or something?)
Yes, I wondered too how we did not see this earlier.
Even now, it happens randomly.
libc log2(0) is not undefined itself, it returns -infinity.
Looking at the test code, ceilf (I would expect ceil) returns
-infinity when getting it passed.
So I'd say the problem lies in the cast to uint32_t.
Both gcc and clang do not seem to bother with standard compilation
flags, and the cast gives 0 on my RHEL.
#include
#include
#include
int main(int argc, char *argv[])
{
printf("%lf %f %"PRIu32"\n", log2(0), (float)log2(0), (uint32_t)log2(0));
return 0;
}
$ ./log2
-inf -inf 0
Now, if I use UBSAN with clang, I get a complaint at runtime:
$ ./log2
(/home/dmarchan/log2+0x41dfa5): runtime error: value -inf is outside
the range of representable values of type 'unsigned int'
-inf -inf 0
Not sure if it explains the random failures, but won't undefined
behavior eat your babies?
--
David Marchand
[dpdk-dev] [Bug 376] mlx5 / DPDK 19.11 : single core throughput dropped at testpmd (VS DPDK 19.08)
https://bugs.dpdk.org/show_bug.cgi?id=376 Bug ID: 376 Summary: mlx5 / DPDK 19.11 : single core throughput dropped at testpmd (VS DPDK 19.08) Product: DPDK Version: unspecified Hardware: ARM OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: testpmd Assignee: dev@dpdk.org Reporter: jerry...@os.amperecomputing.com Target Milestone: --- Linux 5.0.0-32-generic gcc version 9.1.0 dpdk 19.11 Mellanox NIC: MCX516A-CDAT run testpmd with below commands. ./arm64-armv8a-linuxapp-gcc/app/testpmd -c 0xfff8 -n 8 -r 2 -w :01:00.0 -- -i --nb-cores=1 --burst=64 --rss-ip --txq=1 --rxq=1 --mbcache=512 --rxd=1024 --txd=1024 Comparing with DPDK 19.08, at testpmd fwd io (default) mode, the single core throughput (pps) dropped about ~9%. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] Sharing Data structure between logical cores in DPDK- regarding
Hi All, I have a small doubt, can we share a data structure between multiple logical cores in DPDK without locking? I have tested it by sharing a small structure with two variable and incrementing them in all logical cores. It ran smooth I didn't get any issue. But I doubt if we can run it for long time with some huge data structure having many elements getting accessed by multiple logical cores. Can anyone please clarify this. Thanks and regards, Hemasai.
Re: [dpdk-dev] Sharing Data structure between logical cores in DPDK- regarding
It depends on the datastructure. If you use rte_hash, with the thread safety flags, it's safe. In any case having a lot of cores accessing the same DS will lead to bad performance. You should try to have per-core data structures whenever possible. Tom De : dev de la part de Perugu Hemasai Chandra Prasad Envoyé : jeudi 5 décembre 2019 11:16 À : us...@dpdk.org; dev@dpdk.org Objet : [dpdk-dev] Sharing Data structure between logical cores in DPDK- regarding Hi All, I have a small doubt, can we share a data structure between multiple logical cores in DPDK without locking? I have tested it by sharing a small structure with two variable and incrementing them in all logical cores. It ran smooth I didn't get any issue. But I doubt if we can run it for long time with some huge data structure having many elements getting accessed by multiple logical cores. Can anyone please clarify this. Thanks and regards, Hemasai.
[dpdk-dev] example/kni failed
when I run the example/kni -l0-4 -- -P -p1 -m --config="(0,1,2)" in my physical machine, I don't get the dpdk virtual networke interface vEth(N) by ifconfig and the virtual interface is not active. but, I run the example in vm (linux in vmware),I can get a active virtual interface, so,,,why is not active in physical machin ? thanks! dmesg of insmod igb_uio: [ 634.971691] igb_uio: loading out-of-tree module taints kernel. [ 634.971898] igb_uio: module verification failed: signature and/or required key missing - tainting kernel [ 634.972563] igb_uio: Use MSIX interrupt by default [ 635.250107] igb :02:00.0: removed PHC on eth0 [ 635.318925] igb_uio :02:00.0: mapping 1K dma=0x82cae2000 host=99a96cae2000 [ 635.318950] igb_uio :02:00.0: unmapping 1K dma=0x82cae2000 host=99a96cae2000 dmesg of run example kni [ 978.094385] igb_uio :02:00.0: irq 35 for MSI/MSI-X [ 978.094435] igb_uio :02:00.0: uio device registered with irq 35 [ 978.402505] rte_kni: Creating kni... [ 1003.513392] rte_kni: Successfully release kni named vEth0 OS:centos 7.2.1511 kernel 3.10.0-1062.4.3.el7.x86_64 network:I350 Gigabit Network Connection 1521 thanks!
Re: [dpdk-dev] [dpdk-users] Sharing Data structure between logical cores in DPDK- regarding
> -Original Message- > From: users On Behalf Of Tom Barbette > Sent: Thursday, December 5, 2019 10:42 AM > To: Perugu Hemasai Chandra Prasad ; > us...@dpdk.org; dev@dpdk.org > Subject: Re: [dpdk-users] [dpdk-dev] Sharing Data structure between logical > cores in DPDK- regarding > > It depends on the datastructure. > > If you use rte_hash, with the thread safety flags, it's safe. > > In any case having a lot of cores accessing the same DS will lead to bad > performance. You should try to have per-core data structures whenever > possible. > > Tom > > > De : dev de la part de Perugu Hemasai Chandra Prasad > > Envoyé : jeudi 5 décembre 2019 11:16 > À : us...@dpdk.org; dev@dpdk.org > Objet : [dpdk-dev] Sharing Data structure between logical cores in DPDK- > regarding > > Hi All, Hi! > I have a small doubt, can we share a data structure between > multiple logical cores in DPDK without locking? Note that "locking" and "atomic instructions" are not the same. So locking a mutex is only one way of ensuring multiple cores have a coherent view on the datastructure. The other method of doing "lock free" but multi-core safe data-structures is by using Atomic instructions, which ensure that results are observed correctly on all cores accessing that data-structure. A good example is the Multi-producer or Multi-consumer versions of the DPDK rte_ring ringbuffer. Regards, -Harry > I have tested it by sharing > a small structure with two variable and incrementing them in all logical > cores. It ran smooth I didn't get any issue. But I doubt if we can run it > for long time with some huge data structure having many elements getting > accessed by multiple logical cores. > Can anyone please clarify this. > > Thanks and regards, > Hemasai.
[dpdk-dev] [PATCH 1/4] lib/crypto: add support for ECDSA
From: Ayuj Verma
Elliptic curve xform and ECDSA op params are added.
Signed-off-by: Anoob Joseph
Signed-off-by: Ayuj Verma
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/default.ini | 11 ++--
lib/librte_cryptodev/rte_crypto_asym.h | 83 ++
lib/librte_cryptodev/rte_cryptodev.c | 1 +
3 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/doc/guides/cryptodevs/features/default.ini
b/doc/guides/cryptodevs/features/default.ini
index b7f9a0a..2f6c785 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -103,8 +103,9 @@ AES CCM (256) =
; Supported Asymmetric algorithms of a default crypto driver.
;
[Asymmetric]
-RSA =
-DSA =
-Modular Exponentiation =
-Modular Inversion =
-Diffie-hellman =
\ No newline at end of file
+RSA =
+DSA =
+Modular Exponentiation =
+Modular Inversion =
+Diffie-hellman =
+ECDSA =
diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
b/lib/librte_cryptodev/rte_crypto_asym.h
index 0d34ce8..dd5e6e3 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -81,6 +81,10 @@ enum rte_crypto_asym_xform_type {
/**< Modular Exponentiation
* Perform Modular Exponentiation b^e mod n
*/
+ RTE_CRYPTO_ASYM_XFORM_ECDSA,
+ /**< Elliptic Curve Digital Signature Algorithm
+* Perform Signature Generation and Verification.
+*/
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
/**< End of list */
};
@@ -319,6 +323,46 @@ struct rte_crypto_dsa_xform {
};
/**
+ * TLS named curves
+ * https://www.iana.org/assignments/tls-parameters/
+ * tls-parameters.xhtml#tls-parameters-8
+ * secp192r1 = 19,
+ * secp224r1 = 21,
+ * secp256r1 = 23,
+ * secp384r1 = 24,
+ * secp521r1 = 25,
+ */
+enum rte_crypto_ec_group {
+ RTE_CRYPTO_EC_GROUP_UNKNOWN = 0,
+ RTE_CRYPTO_EC_GROUP_NISTP192 = 19,
+ RTE_CRYPTO_EC_GROUP_NISTP224 = 21,
+ RTE_CRYPTO_EC_GROUP_NISTP256 = 23,
+ RTE_CRYPTO_EC_GROUP_NISTP384 = 24,
+ RTE_CRYPTO_EC_GROUP_NISTP521 = 25,
+};
+
+/**
+ * Structure for elliptic curve point
+ */
+struct rte_crypto_ec_point {
+ rte_crypto_param x;
+ /**< X coordinate */
+ rte_crypto_param y;
+ /**< Y coordinate */
+};
+
+/**
+ * Asymmetric elliptic curve transform data
+ *
+ * Structure describing all EC based xform params
+ *
+ */
+struct rte_crypto_ec_xform {
+ enum rte_crypto_ec_group curve_id;
+ /**< Pre-defined ec groups */
+};
+
+/**
* Operations params for modular operations:
* exponentiation and multiplicative inverse
*
@@ -372,6 +416,11 @@ struct rte_crypto_asym_xform {
struct rte_crypto_dsa_xform dsa;
/**< DSA xform parameters */
+
+ struct rte_crypto_ec_xform ec;
+ /**< EC xform parameters, used by elliptic curve based
+* operations.
+*/
};
};
@@ -516,6 +565,39 @@ struct rte_crypto_dsa_op_param {
};
/**
+ * ECDSA operation params
+ */
+struct rte_crypto_ecdsa_op_param {
+ enum rte_crypto_asym_op_type op_type;
+ /**< Signature generation or verification */
+
+ rte_crypto_param pkey;
+ /**< Private key of the signer for signature generation */
+
+ struct rte_crypto_ec_point q;
+ /**< Public key of the signer for verification */
+
+ rte_crypto_param message;
+ /**< Input message to be signed or verified */
+
+ rte_crypto_param k;
+ /**< The ECDSA per-message secret number, which is an integer
+* in the interval (1, n-1)
+*/
+
+ rte_crypto_param r;
+ /**< r component of elliptic curve signature
+* output : for signature generation
+* input : for signature verification
+*/
+ rte_crypto_param s;
+ /**< s component of elliptic curve signature
+* output : for signature generation
+* input : for signature verification
+*/
+};
+
+/**
* Asymmetric Cryptographic Operation.
*
* Structure describing asymmetric crypto operation params.
@@ -537,6 +619,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_mod_op_param modinv;
struct rte_crypto_dh_op_param dh;
struct rte_crypto_dsa_op_param dsa;
+ struct rte_crypto_ecdsa_op_param ecdsa;
};
};
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index 89aa2ed..0d6babb 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -173,6 +173,7 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_MODINV] = "modinv",
[RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
[RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
};
/**
--
[dpdk-dev] [PATCH 0/4] add ECDSA support
This series adds support for ECDSA asymmetric operations. Library changes and PMD changes for crypto_octeontx & crypto_octoentx2 is added. The final patch adds the required test vectors and verification routines. Ayuj Verma (2): lib/crypto: add support for ECDSA app/test: add ECDSA sign/verify tests Sunila Sahu (2): crypto/octeontx: add ECDSA support crypto/octeontx2: add ECDSA support app/test/test_cryptodev_asym.c | 219 +++- app/test/test_cryptodev_asym_util.h| 11 + app/test/test_cryptodev_ecdsa_test_vectors.h | 501 + doc/guides/cryptodevs/features/default.ini | 11 +- doc/guides/cryptodevs/features/octeontx.ini|8 +- doc/guides/cryptodevs/features/octeontx2.ini |8 +- drivers/common/cpt/Makefile|1 + drivers/common/cpt/cpt_fpm_tables.c| 1138 drivers/common/cpt/cpt_mcode_defines.h | 38 + drivers/common/cpt/cpt_pmd_ops_helper.h| 19 + drivers/common/cpt/cpt_ucode_asym.h| 378 +++ drivers/common/cpt/meson.build |3 +- drivers/common/cpt/rte_common_cpt_version.map |9 + .../crypto/octeontx/otx_cryptodev_capabilities.c | 11 + drivers/crypto/octeontx/otx_cryptodev_ops.c| 43 +- .../crypto/octeontx2/otx2_cryptodev_capabilities.c | 11 + drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 39 +- lib/librte_cryptodev/rte_crypto_asym.h | 83 ++ lib/librte_cryptodev/rte_cryptodev.c |1 + 19 files changed, 2517 insertions(+), 15 deletions(-) create mode 100644 app/test/test_cryptodev_ecdsa_test_vectors.h create mode 100644 drivers/common/cpt/cpt_fpm_tables.c -- 2.7.4
[dpdk-dev] [PATCH 2/4] crypto/octeontx: add ECDSA support
From: Sunila Sahu
Adding support for ECDSA operations in crypto_octeontx PMD.
Signed-off-by: Anoob Joseph
Signed-off-by: Ayuj Verma
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/octeontx.ini|8 +-
drivers/common/cpt/Makefile|1 +
drivers/common/cpt/cpt_fpm_tables.c| 1138
drivers/common/cpt/cpt_mcode_defines.h | 38 +
drivers/common/cpt/cpt_pmd_ops_helper.h| 19 +
drivers/common/cpt/cpt_ucode_asym.h| 378 +++
drivers/common/cpt/meson.build |3 +-
drivers/common/cpt/rte_common_cpt_version.map |9 +
.../crypto/octeontx/otx_cryptodev_capabilities.c | 11 +
drivers/crypto/octeontx/otx_cryptodev_ops.c| 43 +-
10 files changed, 1643 insertions(+), 5 deletions(-)
create mode 100644 drivers/common/cpt/cpt_fpm_tables.c
diff --git a/doc/guides/cryptodevs/features/octeontx.ini
b/doc/guides/cryptodevs/features/octeontx.ini
index 1c036c5..544bb46 100644
--- a/doc/guides/cryptodevs/features/octeontx.ini
+++ b/doc/guides/cryptodevs/features/octeontx.ini
@@ -67,5 +67,9 @@ AES GCM (256) = Y
; Supported Asymmetric algorithms of the 'octeontx' crypto driver.
;
[Asymmetric]
-RSA= Y
-Modular Exponentiation = Y
+RSA = Y
+DSA =
+Modular Exponentiation = Y
+Modular Inversion =
+Diffie-hellman =
+ECDSA = Y
diff --git a/drivers/common/cpt/Makefile b/drivers/common/cpt/Makefile
index 8594432..cab9da7 100644
--- a/drivers/common/cpt/Makefile
+++ b/drivers/common/cpt/Makefile
@@ -16,6 +16,7 @@ EXPORT_MAP := rte_common_cpt_version.map
#
# all source are stored in SRCS-y
#
+SRCS-y += cpt_fpm_tables.c
SRCS-y += cpt_pmd_ops_helper.c
LDLIBS += -lrte_eal
diff --git a/drivers/common/cpt/cpt_fpm_tables.c
b/drivers/common/cpt/cpt_fpm_tables.c
new file mode 100644
index 000..15b665d
--- /dev/null
+++ b/drivers/common/cpt/cpt_fpm_tables.c
@@ -0,0 +1,1138 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) 2019 Marvell International Ltd.
+ */
+
+#include
+#include
+
+#include "cpt_mcode_defines.h"
+#include "cpt_pmd_logs.h"
+#include "cpt_pmd_ops_helper.h"
+
+/*
+ * CPT FPM table sizes Enumeration
+ *
+ * 15 table entries * (X, Y, Z coordinates) * Coordinate Offset
+ * Coordinate Offset depends on elliptic curve as mentioned below,
+ * 6 quadwords for P-192, P-224 and P-256
+ * 7 quadwords for P-384
+ * 9 quadwords for P-521
+ */
+typedef enum {
+ CPT_P192_LEN = 2160,
+ CPT_P224_LEN = 2160,
+ CPT_P256_LEN = 2160,
+ CPT_P384_LEN = 2520,
+ CPT_P521_LEN = 3240
+} cpt_fpm_len_t;
+
+/* FPM table address and length */
+struct fpm_entry {
+ const uint8_t *data;
+ int len;
+};
+
+/*
+ * Pre-computed ECC FMUL tables needed by cpt microcode
+ * for NIST curves P-192, P-256, P-384, P-521, P-224.
+ */
+
+static const uint8_t fpm_table_p192[CPT_P192_LEN] = {
+ 0xf4, 0xff, 0x0a, 0xfd, 0x82, 0xff, 0x10, 0x12, 0x7c, 0xbf, 0x20, 0xeb,
+ 0x43, 0xa1, 0x88, 0x00, 0x18, 0x8d, 0xa8, 0x0e, 0xb0, 0x30, 0x90, 0xf6,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x73, 0xf9, 0x77, 0xa1, 0x1e, 0x79, 0x48, 0x11, 0x63, 0x10, 0x11, 0xed,
+ 0x6b, 0x24, 0xcd, 0xd5, 0x07, 0x19, 0x2b, 0x95, 0xff, 0xc8, 0xda, 0x78,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0xc3, 0x96, 0x49, 0xc5, 0x5d, 0x7c, 0x48, 0xd8, 0xeb, 0x2c, 0xdf, 0xae,
+ 0x5a, 0x92, 0x7c, 0x35, 0x67, 0xe3, 0x0c, 0xbd, 0xcb, 0xa6, 0x71, 0xfb,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x7a, 0x83, 0xce, 0xe1, 0xec, 0xbf, 0xbe, 0x7d, 0xce, 0x32, 0xd0, 0x3c,
+ 0x06, 0x30, 0x15, 0x77, 0xa9, 0x35, 0x49, 0xc4, 0x58, 0x10, 0xf5, 0xc3,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x6f, 0x5e, 0xf8, 0x89, 0x66, 0xe3, 0xea, 0xd3, 0xf2, 0
[dpdk-dev] [PATCH 3/4] crypto/octeontx2: add ECDSA support
From: Sunila Sahu
Adding support for ECDSA operations in crypto_octeontx2 PMD.
Signed-off-by: Anoob Joseph
Signed-off-by: Balakrishna Bhamidipati
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/octeontx2.ini | 8 +++--
.../crypto/octeontx2/otx2_cryptodev_capabilities.c | 11 ++
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 39 --
3 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/doc/guides/cryptodevs/features/octeontx2.ini
b/doc/guides/cryptodevs/features/octeontx2.ini
index 7d07053..dd6369b 100644
--- a/doc/guides/cryptodevs/features/octeontx2.ini
+++ b/doc/guides/cryptodevs/features/octeontx2.ini
@@ -67,5 +67,9 @@ AES GCM (256) = Y
; Supported Asymmetric algorithms of the 'octeontx2' crypto driver.
;
[Asymmetric]
-RSA= Y
-Modular Exponentiation = Y
+RSA = Y
+DSA =
+Modular Exponentiation = Y
+Modular Inversion =
+Diffie-hellman =
+ECDSA = Y
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
b/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
index b9e3fe3..f2079e2 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
@@ -628,6 +628,17 @@ rte_cryptodev_capabilities otx2_cpt_capabilities[] = {
}
}, }
},
+ { /* ECDSA */
+ .op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
+ {.asym = {
+ .xform_capa = {
+ .xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA,
+ .op_types = ((1 << RTE_CRYPTO_ASYM_OP_SIGN) |
+ (1 << RTE_CRYPTO_ASYM_OP_VERIFY)),
+ }
+ },
+ }
+ },
/* End of asymmetric capabilities */
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
};
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 65101b0..17c755d 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -22,6 +22,8 @@
#define METABUF_POOL_CACHE_SIZE512
+static uint64_t otx2_fpm_iova[CPT_EC_ID_PMAX];
+
/* Forward declarations */
static int
@@ -440,6 +442,11 @@ otx2_cpt_enqueue_asym(struct otx2_cpt_qp *qp,
if (unlikely(ret))
goto req_fail;
break;
+ case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+ ret = cpt_enqueue_ecdsa_op(op, ¶ms, sess, otx2_fpm_iova);
+ if (unlikely(ret))
+ goto req_fail;
+ break;
default:
op->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
ret = -EINVAL;
@@ -641,6 +648,23 @@ otx2_cpt_asym_rsa_op(struct rte_crypto_op *cop, struct
cpt_request_info *req,
}
}
+static __rte_always_inline void
+otx2_cpt_asym_dequeue_ecdsa_op(struct rte_crypto_ecdsa_op_param *ecdsa,
+ struct cpt_request_info *req,
+ struct cpt_asym_ec_ctx *ec)
+{
+ int prime_len = ec_grp[ec->curveid].prime.length;
+
+ if (ecdsa->op_type == RTE_CRYPTO_ASYM_OP_VERIFY)
+ return;
+
+ /* Separate out sign r and s components */
+ memcpy(ecdsa->r.data, req->rptr, prime_len);
+ memcpy(ecdsa->s.data, req->rptr + ROUNDUP8(prime_len), prime_len);
+ ecdsa->r.length = prime_len;
+ ecdsa->s.length = prime_len;
+}
+
static void
otx2_cpt_asym_post_process(struct rte_crypto_op *cop,
struct cpt_request_info *req)
@@ -660,6 +684,9 @@ otx2_cpt_asym_post_process(struct rte_crypto_op *cop,
memcpy(op->modex.result.data, req->rptr,
op->modex.result.length);
break;
+ case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+ otx2_cpt_asym_dequeue_ecdsa_op(&op->ecdsa, req, &sess->ec_ctx);
+ break;
default:
CPT_LOG_DP_DEBUG("Invalid crypto xform type");
cop->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
@@ -824,6 +851,13 @@ otx2_cpt_dev_config(struct rte_cryptodev *dev,
dev->feature_flags &= ~conf->ff_disable;
+ if (dev->feature_flags & RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO) {
+ /* Initialize shared FPM table */
+ ret = cpt_fpm_init(otx2_fpm_iova);
+ if (ret)
+ return ret;
+ }
+
/* Unregister error interrupts */
if (vf->err_intr_registered)
otx2_cpt_err_intr_unregister(dev);
@@ -881,9 +915,10 @@ otx2_cpt_dev_start(struct rte_cryptodev *dev)
static void
otx2_cpt_dev_stop(struct rte_cryptodev *dev)
{
- RTE_SET_USED(dev);
-
CPT_PMD_INIT_FUNC_TRACE();
+
+ if (dev->feature_flags & RTE_CRYPTODEV_FF_ASYM
[dpdk-dev] [PATCH 4/4] app/test: add ECDSA sign/verify tests
From: Ayuj Verma
This patch adds ECDSA sign and verify test routine and test vectors.
Signed-off-by: Anoob Joseph
Signed-off-by: Ayuj Verma
Signed-off-by: Sunila Sahu
---
app/test/test_cryptodev_asym.c | 219 +++-
app/test/test_cryptodev_asym_util.h | 11 +
app/test/test_cryptodev_ecdsa_test_vectors.h | 501 +++
3 files changed, 730 insertions(+), 1 deletion(-)
create mode 100644 app/test/test_cryptodev_ecdsa_test_vectors.h
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 69df293..b913a7d 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -18,6 +18,7 @@
#include "test_cryptodev.h"
#include "test_cryptodev_dh_test_vectors.h"
#include "test_cryptodev_dsa_test_vectors.h"
+#include "test_cryptodev_ecdsa_test_vectors.h"
#include "test_cryptodev_mod_test_vectors.h"
#include "test_cryptodev_rsa_test_vectors.h"
#include "test_cryptodev_asym_util.h"
@@ -1037,14 +1038,16 @@ static inline void print_asym_capa(
case RTE_CRYPTO_ASYM_XFORM_MODEX:
case RTE_CRYPTO_ASYM_XFORM_DH:
case RTE_CRYPTO_ASYM_XFORM_DSA:
- printf(" modlen: min %d max %d increment %d\n",
+ printf(" modlen: min %d max %d increment %d",
capa->modlen.min,
capa->modlen.max,
capa->modlen.increment);
break;
+ case RTE_CRYPTO_ASYM_XFORM_ECDSA:
default:
break;
}
+ printf("\n");
}
static int
@@ -1892,6 +1895,218 @@ test_dsa(void)
return status;
}
+static int
+test_ecdsa_sign_verify(enum curve curve_id)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ struct rte_mempool *sess_mpool = ts_params->session_mpool;
+ struct rte_mempool *op_mpool = ts_params->op_mpool;
+ struct crypto_testsuite_ecdsa_params input_params;
+ struct rte_cryptodev_asym_session *sess = NULL;
+ uint8_t dev_id = ts_params->valid_devs[0];
+ struct rte_crypto_op *result_op = NULL;
+ uint8_t output_buf_r[TEST_DATA_SIZE];
+ uint8_t output_buf_s[TEST_DATA_SIZE];
+ struct rte_crypto_asym_xform xform;
+ struct rte_crypto_asym_op *asym_op;
+ struct rte_cryptodev_info dev_info;
+ struct rte_crypto_op *op = NULL;
+ int status = TEST_SUCCESS, ret;
+
+ switch (curve_id) {
+ case P192:
+ input_params = ecdsa_param_p192;
+ break;
+ case P224:
+ input_params = ecdsa_param_p224;
+ break;
+ case P256:
+ input_params = ecdsa_param_p256;
+ break;
+ case P384:
+ input_params = ecdsa_param_p384;
+ break;
+ case P521:
+ input_params = ecdsa_param_p521;
+ break;
+ default:
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Unsupported curve id\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ rte_cryptodev_info_get(dev_id, &dev_info);
+
+ sess = rte_cryptodev_asym_session_create(sess_mpool);
+ if (sess == NULL) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Session creation failed\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ /* Setup crypto op data structure */
+ op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
+ if (op == NULL) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Failed to allocate asymmetric crypto "
+ "operation struct\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+ asym_op = op->asym;
+
+ /* Setup asym xform */
+ xform.next = NULL;
+ xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
+ xform.ec.curve_id = input_params.curve;
+
+ if (rte_cryptodev_asym_session_init(dev_id, sess, &xform,
+ sess_mpool) < 0) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Unable to config asym session\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ /* Attach asymmetric crypto session to crypto operations */
+ rte_crypto_op_attach_asym_session(op, sess);
+
+ /* Compute sign */
+
+ /* Populate op with operational details */
+ op->asym->ecdsa.op_type = RTE_CRYPTO_ASYM_OP_SIGN;
+ op->asym->ecdsa.message.data = input_params.dige
[dpdk-dev] [PATCH 00/12] base code update
Main changes: 1. add support for MAC rules on specific port 2. support MAC/VLAN with TCP/UDP in switch rule 3. support 1/10G device 4. couple bug fix and code clean. Qi Zhang (12): net/ice/base: whitelist register for NVM access net/ice/base: support MAC/VLAN with TCP/UDP in switch net/ice/base: do not wait for PE unit to load net/ice/base: cleanup format of static const declarations net/ice/base: flexbytes should match on header data net/ice/base: enable clearing of the HW tables net/ice/base: fix loop limit net/ice/base: increase PF reset wait timeout net/ice/base: change fdir desc preparation net/ice/base: support add MAC rules on specific port net/ice: support 1/10G device IDs net/ice/base: minor code clean drivers/net/ice/base/ice_adminq_cmd.h | 1 + drivers/net/ice/base/ice_common.c | 26 +- drivers/net/ice/base/ice_devids.h | 4 + drivers/net/ice/base/ice_fdir.c | 92 +++--- drivers/net/ice/base/ice_flex_pipe.c | 63 - drivers/net/ice/base/ice_flex_pipe.h | 1 + drivers/net/ice/base/ice_flow.c | 17 +- drivers/net/ice/base/ice_flow.h | 2 +- drivers/net/ice/base/ice_nvm.c| 10 +- drivers/net/ice/base/ice_switch.c | 517 +- drivers/net/ice/base/ice_switch.h | 3 +- drivers/net/ice/base/ice_type.h | 4 - drivers/net/ice/ice_ethdev.c | 2 + 13 files changed, 534 insertions(+), 208 deletions(-) -- 2.13.6
[dpdk-dev] [PATCH 01/12] net/ice/base: whitelist register for NVM access
Allow tools to access register offset 0xB8188 (GLGEN_RSTAT) for
NVMUpdate operations. This is a read-only register, so risk of other
issues stemming from this change is low. Even so, update the write
command to prevent and reject any commands which attempt to write to
this register, just like we do for GL_HICR_EN.
Signed-off-by: Jeb Cramer
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_nvm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ice/base/ice_nvm.c b/drivers/net/ice/base/ice_nvm.c
index 1dbfc2dcc..2d92524f2 100644
--- a/drivers/net/ice/base/ice_nvm.c
+++ b/drivers/net/ice/base/ice_nvm.c
@@ -504,6 +504,7 @@ ice_validate_nvm_rw_reg(struct ice_nvm_access_cmd *cmd)
case GL_FWSTS:
case GL_MNG_FWSM:
case GLGEN_CSR_DEBUG_C:
+ case GLGEN_RSTAT:
case GLPCI_LBARCTRL:
case GLNVM_GENS:
case GLNVM_FLA:
@@ -579,9 +580,14 @@ ice_nvm_access_write(struct ice_hw *hw, struct
ice_nvm_access_cmd *cmd,
if (status)
return status;
- /* The HICR_EN register is read-only */
- if (cmd->offset == GL_HICR_EN)
+ /* Reject requests to write to read-only registers */
+ switch (cmd->offset) {
+ case GL_HICR_EN:
+ case GLGEN_RSTAT:
return ICE_ERR_OUT_OF_RANGE;
+ default:
+ break;
+ }
ice_debug(hw, ICE_DBG_NVM,
"NVM access: writing register %08x with value %08x\n",
--
2.13.6
[dpdk-dev] [PATCH 02/12] net/ice/base: support MAC/VLAN with TCP/UDP in switch
Add a feature to allow user to add switch filter using input like
MAC + VLAN (C-tag only) + L4 (TCP/UDP) port. API "ice_add_adv_rule"
is extended to handle this filter type.
Signed-off-by: Kiran Patil
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_switch.c | 206 ++
1 file changed, 188 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index afa4fe30d..f8f5fde3c 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -251,8 +251,8 @@ u8 dummy_udp_tun_udp_packet[] = {
0x00, 0x08, 0x00, 0x00,
};
-static const
-struct ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
+/* offset info for MAC + IPv4 + UDP dummy packet */
+static const struct ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -260,8 +260,8 @@ struct ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_udp_packet[] = {
+/* Dummy packet for MAC + IPv4 + UDP */
+static const u8 dummy_udp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -280,8 +280,40 @@ dummy_udp_packet[] = {
0x00, 0x00, /* 2 bytes for 4 byte alignment */
};
-static const
-struct ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
+/* offset info for MAC + VLAN + IPv4 + UDP dummy packet */
+static const struct ice_dummy_pkt_offsets dummy_vlan_udp_packet_offsets[] = {
+ { ICE_MAC_OFOS, 0 },
+ { ICE_ETYPE_OL, 12 },
+ { ICE_VLAN_OFOS,14 },
+ { ICE_IPV4_OFOS,18 },
+ { ICE_UDP_ILOS, 38 },
+ { ICE_PROTOCOL_LAST,0 },
+};
+
+/* C-tag (801.1Q), IPv4:UDP dummy packet */
+static const u8 dummy_vlan_udp_packet[] = {
+ 0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x81, 0x00, /* ICE_ETYPE_OL 12 */
+
+ 0x00, 0x00, 0x08, 0x00, /* ICE_VLAN_OFOS 14 */
+
+ 0x45, 0x00, 0x00, 0x1c, /* ICE_IPV4_OFOS 18 */
+ 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x11, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, 0x00, 0x00, /* ICE_UDP_ILOS 38 */
+ 0x00, 0x08, 0x00, 0x00,
+
+ 0x00, 0x00, /* 2 bytes for 4 byte alignment */
+};
+
+/* offset info for MAC + IPv4 + TCP dummy packet */
+static const struct ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -289,8 +321,8 @@ struct ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_tcp_packet[] = {
+/* Dummy packet for MAC + IPv4 + TCP */
+static const u8 dummy_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -312,8 +344,42 @@ dummy_tcp_packet[] = {
0x00, 0x00, /* 2 bytes for 4 byte alignment */
};
-static const
-struct ice_dummy_pkt_offsets dummy_tcp_ipv6_packet_offsets[] = {
+/* offset info for MAC + VLAN (C-tag, 802.1Q) + IPv4 + TCP dummy packet */
+static const struct ice_dummy_pkt_offsets dummy_vlan_tcp_packet_offsets[] = {
+ { ICE_MAC_OFOS, 0 },
+ { ICE_ETYPE_OL, 12 },
+ { ICE_VLAN_OFOS,14 },
+ { ICE_IPV4_OFOS,18 },
+ { ICE_TCP_IL, 38 },
+ { ICE_PROTOCOL_LAST,0 },
+};
+
+/* C-tag (801.1Q), IPv4:TCP dummy packet */
+static const u8 dummy_vlan_tcp_packet[] = {
+ 0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x81, 0x00, /* ICE_ETYPE_OL 12 */
+
+ 0x00, 0x00, 0x08, 0x00, /* ICE_VLAN_OFOS 14 */
+
+ 0x45, 0x00, 0x00, 0x28, /* ICE_IPV4_OFOS 18 */
+ 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x06, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, 0x00, 0x00, /* ICE_TCP_IL 38 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x50, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, /* 2 bytes for 4 byte alignment */
+};
+
+static const struct ice_dummy_pkt_offsets dummy_tcp_ipv6_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV6_OFOS,14 },
@@ -349,8 +415,49 @@ dummy_tcp_ipv6_packet[] = {
0x00, 0x00, /* 2 bytes for 4 byte alignment */
};
-static const
-struct ice_dummy_pkt_offsets dummy_udp_ipv6_packet_offsets[] = {
+/* C-tag (802.1Q): IPv6 + TCP */
+static const struct ice_dummy_pkt_offsets
+dummy_vlan_tcp_ipv6_pack
[dpdk-dev] [PATCH 04/12] net/ice/base: cleanup format of static const declarations
Use a format consistent with the rest of the code.
Signed-off-by: Bruce Allan
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_switch.c | 40 ++-
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index f8f5fde3c..3ed84ca01 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -57,8 +57,7 @@ struct ice_dummy_pkt_offsets {
u16 offset; /* ICE_PROTOCOL_LAST indicates end of list */
};
-static const
-struct ice_dummy_pkt_offsets dummy_gre_tcp_packet_offsets[] = {
+static const struct ice_dummy_pkt_offsets dummy_gre_tcp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -69,8 +68,7 @@ struct ice_dummy_pkt_offsets dummy_gre_tcp_packet_offsets[] =
{
{ ICE_PROTOCOL_LAST,0 },
};
-static const
-u8 dummy_gre_tcp_packet[] = {
+static const u8 dummy_gre_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -104,8 +102,7 @@ u8 dummy_gre_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00
};
-static const
-struct ice_dummy_pkt_offsets dummy_gre_udp_packet_offsets[] = {
+static const struct ice_dummy_pkt_offsets dummy_gre_udp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -116,8 +113,7 @@ struct ice_dummy_pkt_offsets dummy_gre_udp_packet_offsets[]
= {
{ ICE_PROTOCOL_LAST,0 },
};
-static const
-u8 dummy_gre_udp_packet[] = {
+static const u8 dummy_gre_udp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -148,8 +144,7 @@ u8 dummy_gre_udp_packet[] = {
0x00, 0x08, 0x00, 0x00,
};
-static const
-struct ice_dummy_pkt_offsets dummy_udp_tun_tcp_packet_offsets[] = {
+static const struct ice_dummy_pkt_offsets dummy_udp_tun_tcp_packet_offsets[] =
{
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -163,8 +158,7 @@ struct ice_dummy_pkt_offsets
dummy_udp_tun_tcp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const
-u8 dummy_udp_tun_tcp_packet[] = {
+static const u8 dummy_udp_tun_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -201,8 +195,7 @@ u8 dummy_udp_tun_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00
};
-static const
-struct ice_dummy_pkt_offsets dummy_udp_tun_udp_packet_offsets[] = {
+static const struct ice_dummy_pkt_offsets dummy_udp_tun_udp_packet_offsets[] =
{
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -216,8 +209,7 @@ struct ice_dummy_pkt_offsets
dummy_udp_tun_udp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const
-u8 dummy_udp_tun_udp_packet[] = {
+static const u8 dummy_udp_tun_udp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -387,8 +379,7 @@ static const struct ice_dummy_pkt_offsets
dummy_tcp_ipv6_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_tcp_ipv6_packet[] = {
+static const u8 dummy_tcp_ipv6_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -465,8 +456,8 @@ static const struct ice_dummy_pkt_offsets
dummy_udp_ipv6_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_udp_ipv6_packet[] = {
+/* IPv6 + UDP dummy packet */
+static const u8 dummy_udp_ipv6_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -536,8 +527,7 @@ static const struct ice_dummy_pkt_offsets
dummy_udp_gtp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_udp_gtp_packet[] = {
+static const u8 dummy_udp_gtp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -560,8 +550,7 @@ dummy_udp_gtp_packet[] = {
0x00, 0x00, 0x00, 0x00,
};
-static const
-struct ice_dummy_pkt_offsets dummy_pppoe_packet_offsets[] = {
+static const struct ice_dummy_pkt_offsets dummy_pppoe_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_VLAN_OFOS,14},
@@ -569,8 +558,7 @@ struct ice_dummy_pkt_offsets dummy_pppoe_packet_offsets[] =
{
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_pppoe_packet[] = {
+static const u8 dummy_pppoe_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_M
[dpdk-dev] [PATCH 03/12] net/ice/base: do not wait for PE unit to load
When RDMA is not enabled, when checking for completion of a CORER or GLOBR
do not wait for the PE unit to be loaded (indicated by GLNVM_ULD register's
PE_DONE bit being set) since that does not happen and will cause issues
such as failing to initialize the device.
Signed-off-by: Bruce Allan
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_common.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index 4ba3ab202..bb763913a 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -325,6 +325,7 @@ ice_aq_get_link_info(struct ice_port_info *pi, bool ena_lse,
if (!pi)
return ICE_ERR_PARAM;
hw = pi->hw;
+
li_old = &pi->phy.link_info_old;
hw_media_type = &pi->phy.media_type;
li = &pi->phy.link_info;
@@ -645,7 +646,6 @@ enum ice_status ice_init_hw(struct ice_hw *hw)
ice_clear_pxe_mode(hw);
-
status = ice_get_caps(hw);
if (status)
goto err_unroll_cqinit;
@@ -666,7 +666,6 @@ enum ice_status ice_init_hw(struct ice_hw *hw)
goto err_unroll_alloc;
hw->evb_veb = true;
-
/* Query the allocated resources for Tx scheduler */
status = ice_sched_query_res_alloc(hw);
if (status) {
@@ -785,7 +784,7 @@ void ice_deinit_hw(struct ice_hw *hw)
*/
enum ice_status ice_check_reset(struct ice_hw *hw)
{
- u32 cnt, reg = 0, grst_delay;
+ u32 cnt, reg = 0, grst_delay, uld_mask;
/* Poll for Device Active state in case a recent CORER, GLOBR,
* or EMPR has occurred. The grst delay value is in 100ms units.
@@ -807,13 +806,20 @@ enum ice_status ice_check_reset(struct ice_hw *hw)
return ICE_ERR_RESET_FAILED;
}
-#define ICE_RESET_DONE_MASK(GLNVM_ULD_CORER_DONE_M | \
-GLNVM_ULD_GLOBR_DONE_M)
+#define ICE_RESET_DONE_MASK(GLNVM_ULD_PCIER_DONE_M |\
+GLNVM_ULD_PCIER_DONE_1_M |\
+GLNVM_ULD_CORER_DONE_M |\
+GLNVM_ULD_GLOBR_DONE_M |\
+GLNVM_ULD_POR_DONE_M |\
+GLNVM_ULD_POR_DONE_1_M |\
+GLNVM_ULD_PCIER_DONE_2_M)
+
+ uld_mask = ICE_RESET_DONE_MASK;
/* Device is Active; check Global Reset processes are done */
for (cnt = 0; cnt < ICE_PF_RESET_WAIT_COUNT; cnt++) {
- reg = rd32(hw, GLNVM_ULD) & ICE_RESET_DONE_MASK;
- if (reg == ICE_RESET_DONE_MASK) {
+ reg = rd32(hw, GLNVM_ULD) & uld_mask;
+ if (reg == uld_mask) {
ice_debug(hw, ICE_DBG_INIT,
"Global reset processes done. %d\n", cnt);
break;
--
2.13.6
[dpdk-dev] [PATCH 06/12] net/ice/base: enable clearing of the HW tables
Enable the code to clear the HW tables.
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flex_pipe.c | 55
drivers/net/ice/base/ice_flex_pipe.h | 1 +
2 files changed, 56 insertions(+)
diff --git a/drivers/net/ice/base/ice_flex_pipe.c
b/drivers/net/ice/base/ice_flex_pipe.c
index e8d4bbee4..28ac3aa75 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -3618,6 +3618,61 @@ static void ice_init_flow_profs(struct ice_hw *hw, u8
blk_idx)
}
/**
+ * ice_clear_hw_tbls - clear HW tables and flow profiles
+ * @hw: pointer to the hardware structure
+ */
+void ice_clear_hw_tbls(struct ice_hw *hw)
+{
+ u8 i;
+
+ for (i = 0; i < ICE_BLK_COUNT; i++) {
+ struct ice_prof_redir *prof_redir = &hw->blk[i].prof_redir;
+ struct ice_prof_tcam *prof = &hw->blk[i].prof;
+ struct ice_xlt1 *xlt1 = &hw->blk[i].xlt1;
+ struct ice_xlt2 *xlt2 = &hw->blk[i].xlt2;
+ struct ice_es *es = &hw->blk[i].es;
+
+ if (hw->blk[i].is_list_init) {
+ ice_free_prof_map(hw, i);
+ ice_free_flow_profs(hw, i);
+ }
+
+ ice_free_vsig_tbl(hw, (enum ice_block)i);
+
+ ice_memset(xlt1->ptypes, 0, xlt1->count * sizeof(*xlt1->ptypes),
+ ICE_NONDMA_MEM);
+ ice_memset(xlt1->ptg_tbl, 0,
+ ICE_MAX_PTGS * sizeof(*xlt1->ptg_tbl),
+ ICE_NONDMA_MEM);
+ ice_memset(xlt1->t, 0, xlt1->count * sizeof(*xlt1->t),
+ ICE_NONDMA_MEM);
+
+ ice_memset(xlt2->vsis, 0, xlt2->count * sizeof(*xlt2->vsis),
+ ICE_NONDMA_MEM);
+ ice_memset(xlt2->vsig_tbl, 0,
+ xlt2->count * sizeof(*xlt2->vsig_tbl),
+ ICE_NONDMA_MEM);
+ ice_memset(xlt2->t, 0, xlt2->count * sizeof(*xlt2->t),
+ ICE_NONDMA_MEM);
+
+ ice_memset(prof->t, 0, prof->count * sizeof(*prof->t),
+ ICE_NONDMA_MEM);
+ ice_memset(prof_redir->t, 0,
+ prof_redir->count * sizeof(*prof_redir->t),
+ ICE_NONDMA_MEM);
+
+ ice_memset(es->t, 0, es->count * sizeof(*es->t),
+ ICE_NONDMA_MEM);
+ ice_memset(es->ref_count, 0, es->count * sizeof(*es->ref_count),
+ ICE_NONDMA_MEM);
+ ice_memset(es->written, 0, es->count * sizeof(*es->written),
+ ICE_NONDMA_MEM);
+ ice_memset(es->mask_ena, 0, es->count * sizeof(*es->mask_ena),
+ ICE_NONDMA_MEM);
+ }
+}
+
+/**
* ice_init_hw_tbls - init hardware table memory
* @hw: pointer to the hardware structure
*/
diff --git a/drivers/net/ice/base/ice_flex_pipe.h
b/drivers/net/ice/base/ice_flex_pipe.h
index ee606af15..fa72e386d 100644
--- a/drivers/net/ice/base/ice_flex_pipe.h
+++ b/drivers/net/ice/base/ice_flex_pipe.h
@@ -71,6 +71,7 @@ ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf, u32
len);
enum ice_status ice_init_hw_tbls(struct ice_hw *hw);
void ice_free_seg(struct ice_hw *hw);
void ice_fill_blk_tbls(struct ice_hw *hw);
+void ice_clear_hw_tbls(struct ice_hw *hw);
void ice_free_hw_tbls(struct ice_hw *hw);
enum ice_status
ice_rem_prof(struct ice_hw *hw, enum ice_block blk, u64 id);
--
2.13.6
[dpdk-dev] [PATCH 05/12] net/ice/base: flexbytes should match on header data
Change the extraction sequence generated by flow director flexbytes to
use package mac protocol. Without this change data in packet headers
cannot be used for flexbyte matching. The old extraction for flex bytes
started at the beginning of the payload which is after the header.
Signed-off-by: Henry Tieman
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flow.c | 17 -
drivers/net/ice/base/ice_flow.h | 2 +-
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index 391df1b54..eaa7a3b96 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -868,20 +868,11 @@ ice_flow_xtract_raws(struct ice_hw *hw, struct
ice_flow_prof_params *params,
raw = ¶ms->prof->segs[seg].raws[i];
- /* Only support matching raw fields in the payload */
- if (raw->off < hdrs_sz)
- return ICE_ERR_PARAM;
-
- /* Convert the segment-relative offset into payload-relative
-* offset.
-*/
- off = raw->off - hdrs_sz;
-
/* Storing extraction information */
- raw->info.xtrct.prot_id = ICE_PROT_PAY;
- raw->info.xtrct.off = (off / ICE_FLOW_FV_EXTRACT_SZ) *
+ raw->info.xtrct.prot_id = ICE_PROT_MAC_OF_OR_S;
+ raw->info.xtrct.off = (raw->off / ICE_FLOW_FV_EXTRACT_SZ) *
ICE_FLOW_FV_EXTRACT_SZ;
- raw->info.xtrct.disp = (off % ICE_FLOW_FV_EXTRACT_SZ) *
+ raw->info.xtrct.disp = (raw->off % ICE_FLOW_FV_EXTRACT_SZ) *
BITS_PER_BYTE;
raw->info.xtrct.idx = params->es_cnt;
@@ -909,7 +900,7 @@ ice_flow_xtract_raws(struct ice_hw *hw, struct
ice_flow_prof_params *params,
else
idx = params->es_cnt;
- params->es[idx].prot_id = ICE_PROT_PAY;
+ params->es[idx].prot_id = raw->info.xtrct.prot_id;
params->es[idx].off = off;
params->es_cnt++;
off += ICE_FLOW_FV_EXTRACT_SZ;
diff --git a/drivers/net/ice/base/ice_flow.h b/drivers/net/ice/base/ice_flow.h
index 4686274af..d7b10ccc3 100644
--- a/drivers/net/ice/base/ice_flow.h
+++ b/drivers/net/ice/base/ice_flow.h
@@ -282,8 +282,8 @@ struct ice_flow_fld_info {
};
struct ice_flow_seg_fld_raw {
- int off;/* Offset from the start of the segment */
struct ice_flow_fld_info info;
+ u16 off;/* Offset from the start of the segment */
};
struct ice_flow_seg_info {
--
2.13.6
[dpdk-dev] [PATCH 10/12] net/ice/base: support add MAC rules on specific port
ice_add_mac_rule allow user to add rule to port based on
hw->port_info->lport number. Function in some case should
allow user to add filter rule on different port, write
another function which implemented that behaviour.
The same situation is which removing mac function.
Add new api function which allow user to choose port on which
rule going to be added. Leave add mac rule function that always
add rule on hw->port_info->lport to avoid changes in components
which don't need to choose different port. Also add function to
remove rule from specific port.
Alloc more switch_info structs to track separately rules for each
port. Choose switch_info struct basing on logic port number
because in fw added rules are connected with port.
Signed-off-by: Michal Swiatkowski
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_common.c | 2 +-
drivers/net/ice/base/ice_switch.c | 269 +-
drivers/net/ice/base/ice_switch.h | 3 +-
3 files changed, 180 insertions(+), 94 deletions(-)
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index f3b10a65d..99ff821ac 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -463,7 +463,7 @@ static enum ice_status ice_init_fltr_mgmt_struct(struct
ice_hw *hw)
INIT_LIST_HEAD(&sw->vsi_list_map_head);
- return ice_init_def_sw_recp(hw);
+ return ice_init_def_sw_recp(hw, &hw->switch_info->recp_list);
}
/**
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index b2945a9e2..085f34406 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -791,11 +791,13 @@ ice_get_recp_to_prof_map(struct ice_hw *hw)
/**
* ice_init_def_sw_recp - initialize the recipe book keeping tables
* @hw: pointer to the HW struct
+ * @recp_list: pointer to sw recipe list
*
* Allocate memory for the entire recipe table and initialize the structures/
* entries corresponding to basic recipes.
*/
-enum ice_status ice_init_def_sw_recp(struct ice_hw *hw)
+enum ice_status
+ice_init_def_sw_recp(struct ice_hw *hw, struct ice_sw_recipe **recp_list)
{
struct ice_sw_recipe *recps;
u8 i;
@@ -813,7 +815,7 @@ enum ice_status ice_init_def_sw_recp(struct ice_hw *hw)
ice_init_lock(&recps[i].filt_rule_lock);
}
- hw->switch_info->recp_list = recps;
+ *recp_list = recps;
return ICE_SUCCESS;
}
@@ -2427,6 +2429,7 @@ ice_create_vsi_list_rule(struct ice_hw *hw, u16
*vsi_handle_arr, u16 num_vsi,
/**
* ice_create_pkt_fwd_rule
* @hw: pointer to the hardware structure
+ * @recp_list: corresponding filter management list
* @f_entry: entry containing packet forwarding information
*
* Create switch rule with given filter information and add an entry
@@ -2434,13 +2437,11 @@ ice_create_vsi_list_rule(struct ice_hw *hw, u16
*vsi_handle_arr, u16 num_vsi,
* and VSI mapping
*/
static enum ice_status
-ice_create_pkt_fwd_rule(struct ice_hw *hw,
+ice_create_pkt_fwd_rule(struct ice_hw *hw, struct ice_sw_recipe *recp_list,
struct ice_fltr_list_entry *f_entry)
{
struct ice_fltr_mgmt_list_entry *fm_entry;
struct ice_aqc_sw_rules_elem *s_rule;
- enum ice_sw_lkup_type l_type;
- struct ice_sw_recipe *recp;
enum ice_status status;
s_rule = (struct ice_aqc_sw_rules_elem *)
@@ -2480,9 +2481,7 @@ ice_create_pkt_fwd_rule(struct ice_hw *hw,
/* The book keeping entries will get removed when base driver
* calls remove filter AQ command
*/
- l_type = fm_entry->fltr_info.lkup_type;
- recp = &hw->switch_info->recp_list[l_type];
- LIST_ADD(&fm_entry->list_entry, &recp->filt_rules);
+ LIST_ADD(&fm_entry->list_entry, &recp_list->filt_rules);
ice_create_pkt_fwd_rule_exit:
ice_free(hw, s_rule);
@@ -2679,21 +2678,18 @@ ice_add_update_vsi_list(struct ice_hw *hw,
/**
* ice_find_rule_entry - Search a rule entry
- * @hw: pointer to the hardware structure
- * @recp_id: lookup type for which the specified rule needs to be searched
+ * @list_head: head of rule list
* @f_info: rule information
*
* Helper function to search for a given rule entry
* Returns pointer to entry storing the rule if found
*/
static struct ice_fltr_mgmt_list_entry *
-ice_find_rule_entry(struct ice_hw *hw, u8 recp_id, struct ice_fltr_info
*f_info)
+ice_find_rule_entry(struct LIST_HEAD_TYPE *list_head,
+ struct ice_fltr_info *f_info)
{
struct ice_fltr_mgmt_list_entry *list_itr, *ret = NULL;
- struct ice_switch_info *sw = hw->switch_info;
- struct LIST_HEAD_TYPE *list_head;
- list_head = &sw->recp_list[recp_id].filt_rules;
LIST_FOR_EACH_ENTRY(list_itr, list_head, ice_fltr_mgmt_list_entry,
list_entry) {
if (!memcmp(&f_info->l_data, &list_itr->fl
[dpdk-dev] [PATCH 09/12] net/ice/base: change fdir desc preparation
Change internal implemenatation of how FD filter programming desc
is prepared. This is to minimize the amount of code needed to prep
the FD filter programming desc (avoid memcpy, etc...) and just use
predefined shifts and mask. This type of change are needed to expedite
FD setup during data path (ADQ uses this codepath during initial
flow setup) and it will also be useful when adding side-band
flow-director filter.
Signed-off-by: Kiran Patil
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_fdir.c | 92 -
1 file changed, 55 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 37b388169..87fa0afba 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -352,35 +352,6 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
#define ICE_FDIR_NUM_PKT ARRAY_SIZE(ice_fdir_pkt)
-/* Flow Direcotr (FD) filter program descriptor Context */
-static const struct ice_ctx_ele ice_fd_fltr_desc_ctx_info[] = {
- /* Field Width LSB */
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, qindex, 11, 0),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, comp_q, 1, 11),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, comp_report,2, 12),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fd_space, 2, 14),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, cnt_index, 13, 16),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, cnt_ena,2, 29),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, evict_ena, 1, 31),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, toq,3, 32),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, toq_prio, 3, 35),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, dpu_recipe, 2, 38),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, drop, 1, 40),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_prio, 3, 41),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_mdid, 4, 44),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_val, 16, 48),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, dtype, 4, 64),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, pcmd, 1, 68),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, desc_prof_prio, 3, 69),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, desc_prof, 6, 72),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fd_vsi, 10, 78),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, swap, 1, 88),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid_prio, 3, 89),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid_mdid, 4, 92),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid, 32, 96),
- { 0 }
-};
-
/**
* ice_set_dflt_val_fd_desc
* @fd_fltr_ctx: pointer to fd filter descriptor
@@ -455,19 +426,66 @@ ice_fdir_get_prgm_desc(struct ice_hw *hw, struct
ice_fdir_fltr *input,
/**
* ice_set_fd_desc_val
- * @fd_fltr_ctx: pointer to fd filter descriptor context
+ * @ctx: pointer to fd filter descriptor context
* @fdir_desc: populated with fd filter descriptor values
*/
void
-ice_set_fd_desc_val(struct ice_fd_fltr_desc_ctx *fd_fltr_ctx,
+ice_set_fd_desc_val(struct ice_fd_fltr_desc_ctx *ctx,
struct ice_fltr_desc *fdir_desc)
{
- u64 ctx_buf[2] = { 0 };
-
- ice_set_ctx((u8 *)fd_fltr_ctx, (u8 *)ctx_buf,
- ice_fd_fltr_desc_ctx_info);
- fdir_desc->qidx_compq_space_stat = CPU_TO_LE64(ctx_buf[0]);
- fdir_desc->dtype_cmd_vsi_fdid = CPU_TO_LE64(ctx_buf[1]);
+ u64 qword;
+
+ /* prep QW0 of FD filter programming desc */
+ qword = ((u64)ctx->qindex << ICE_FXD_FLTR_QW0_QINDEX_S) &
+ ICE_FXD_FLTR_QW0_QINDEX_M;
+ qword |= ((u64)ctx->comp_q << ICE_FXD_FLTR_QW0_COMP_Q_S) &
+ICE_FXD_FLTR_QW0_COMP_Q_M;
+ qword |= ((u64)ctx->comp_report << ICE_FXD_FLTR_QW0_COMP_REPORT_S) &
+ICE_FXD_FLTR_QW0_COMP_REPORT_M;
+ qword |= ((u64)ctx->fd_space << ICE_FXD_FLTR_QW0_FD_SPACE_S) &
+ICE_FXD_FLTR_QW0_FD_SPACE_M;
+ qword |= ((u64)ctx->cnt_index << ICE_FXD_FLTR_QW0_STAT_CNT_S) &
+ICE_FXD_FLTR_QW0_STAT_CNT_M;
+ qword |= ((u64)ctx->cnt_ena << ICE_FXD_FLTR_QW0_STAT_ENA_S) &
+ICE_FXD_FLTR_QW0_STAT_ENA_M;
+ qword |= ((u64)ctx->evict_ena << ICE_FXD_FLTR_QW0_EVICT_ENA_S) &
+ICE_FXD_FLTR_QW0_EVICT_ENA_M;
+ qword |= ((u64)ctx->toq << ICE_FXD_FLTR_QW0_TO_Q_S) &
+ICE_FXD_FLTR_QW0_TO_Q_M;
+ qword |= ((u64)ctx->toq_prio << ICE_FXD_FLTR_QW0_TO_Q_PRI_S) &
+ICE_FXD_FLTR_QW0_TO_Q_PRI_M;
+ qword |= ((u64)ctx->dpu_recipe << ICE_FXD_FLTR_QW0_DPU_RECIPE_S) &
+ICE_
[dpdk-dev] [PATCH 08/12] net/ice/base: increase PF reset wait timeout
Increase the maximum time that the driver will wait for a PF reset
from 200 milliseconds to 300 milliseconds, to account for possibility
of a slightly longer than expected PF reset.
Fixes: 453d087ccaff ("net/ice/base: add common functions")
Cc: sta...@dpdk.org
Signed-off-by: Jacob Keller
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index bb763913a..f3b10a65d 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -9,7 +9,7 @@
#include "ice_flow.h"
#include "ice_switch.h"
-#define ICE_PF_RESET_WAIT_COUNT200
+#define ICE_PF_RESET_WAIT_COUNT300
/**
* ice_set_mac_type - Sets MAC type
--
2.13.6
[dpdk-dev] [PATCH 07/12] net/ice/base: fix loop limit
In ice_prot_type_to_id routine, correct the loop limit check
to use ARRAY_SIZE instead of looking for the array element to
have a specific value.
Fixes: fed0c5ca5f19 ("net/ice/base: support programming a new switch recipe")
Cc: sta...@dpdk.org
Signed-off-by: Dan Nowlin
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_switch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index 3ed84ca01..b2945a9e2 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -4880,7 +4880,7 @@ static bool ice_prot_type_to_id(enum ice_protocol_type
type, u16 *id)
{
u16 i;
- for (i = 0; ice_prot_id_tbl[i].type != ICE_PROTOCOL_LAST; i++)
+ for (i = 0; i < ARRAY_SIZE(ice_prot_id_tbl); i++)
if (ice_prot_id_tbl[i].type == type) {
*id = ice_prot_id_tbl[i].protocol_id;
return true;
--
2.13.6
[dpdk-dev] [PATCH 12/12] net/ice/base: minor code clean
Couple minor code clean include:
1. Improve debug message format.
2. Add missing macro and comment.
3. Remove unnecessary compile options.
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 1 +
drivers/net/ice/base/ice_common.c | 2 +-
drivers/net/ice/base/ice_flex_pipe.c | 8 +---
drivers/net/ice/base/ice_type.h | 4
4 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index e6a1350ba..9a79c7645 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -1688,6 +1688,7 @@ struct ice_aqc_nvm {
#define ICE_AQC_NVM_ACTIV_SEL_NVM BIT(3) /* Write Activate/SR Dump only */
#define ICE_AQC_NVM_ACTIV_SEL_OROM BIT(4)
#define ICE_AQC_NVM_ACTIV_SEL_NETLIST BIT(5)
+#define ICE_AQC_NVM_SPECIAL_UPDATE BIT(6)
#define ICE_AQC_NVM_ACTIV_SEL_MASK MAKEMASK(0x7, 3)
#define ICE_AQC_NVM_FLASH_ONLY BIT(7)
__le16 module_typeid;
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index 99ff821ac..8c2e59918 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -593,7 +593,7 @@ void ice_print_rollback_msg(struct ice_hw *hw)
SNPRINTF(nvm_str, sizeof(nvm_str), "%x.%02x 0x%x %d.%d.%d", ver_hi,
ver_lo, hw->nvm.eetrack, oem_ver, oem_build, oem_patch);
ice_warn(hw,
-"Firmware rollback mode detected. Current version is NVM: %s,
FW: %d.%d. Device may exhibit limited functionality. Refer to the Intel(R)
Ethernet Adapters and Devices User Guide for details on firmware rollback mode",
+"Firmware rollback mode detected. Current version is NVM: %s,
FW: %d.%d. Device may exhibit limited functionality. Refer to the Intel(R)
Ethernet Adapters and Devices User Guide for details on firmware rollback
mode\n",
nvm_str, hw->fw_maj_ver, hw->fw_min_ver);
}
diff --git a/drivers/net/ice/base/ice_flex_pipe.c
b/drivers/net/ice/base/ice_flex_pipe.c
index 28ac3aa75..1598efd67 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -3069,7 +3069,8 @@ ice_free_prof_mask(struct ice_hw *hw, enum ice_block blk,
u16 mask_idx)
hw->blk[blk].masks.masks[mask_idx].idx = 0;
/* update mask as unused entry */
- ice_debug(hw, ICE_DBG_PKG, "Free mask, blk %d, mask %d", blk, mask_idx);
+ ice_debug(hw, ICE_DBG_PKG, "Free mask, blk %d, mask %d\n", blk,
+ mask_idx);
ice_write_prof_mask_reg(hw, blk, mask_idx, 0, 0);
exit_ice_free_prof_mask:
@@ -4173,7 +4174,7 @@ ice_upd_prof_hw(struct ice_hw *hw, enum ice_block blk,
/* update package */
status = ice_update_pkg(hw, ice_pkg_buf(b), 1);
if (status == ICE_ERR_AQ_ERROR)
- ice_debug(hw, ICE_DBG_INIT, "Unable to update HW profile.");
+ ice_debug(hw, ICE_DBG_INIT, "Unable to update HW profile\n");
error_tmp:
ice_pkg_buf_free(hw, b);
@@ -5227,7 +5228,7 @@ ice_adj_prof_priorities(struct ice_hw *hw, enum ice_block
blk, u16 vsig,
* @blk: hardware block
* @vsig: the VSIG to which this profile is to be added
* @hdl: the profile handle indicating the profile to add
- * @rev: true to reverse the additions to the list
+ * @rev: true to add entries to the end of the list
* @chg: the change list
*/
static enum ice_status
@@ -5379,6 +5380,7 @@ ice_create_prof_id_vsig(struct ice_hw *hw, enum ice_block
blk, u16 vsi, u64 hdl,
* @blk: hardware block
* @vsi: the initial VSI that will be in VSIG
* @lst: the list of profile that will be added to the VSIG
+ * @new_vsig: return of new vsig
* @chg: the change list
*/
static enum ice_status
diff --git a/drivers/net/ice/base/ice_type.h b/drivers/net/ice/base/ice_type.h
index a8e4229a1..9773a549f 100644
--- a/drivers/net/ice/base/ice_type.h
+++ b/drivers/net/ice/base/ice_type.h
@@ -14,9 +14,7 @@
#define BITS_PER_BYTE 8
-#ifndef _FORCE_
#define _FORCE_
-#endif
#define ICE_BYTES_PER_WORD 2
#define ICE_BYTES_PER_DWORD4
@@ -130,9 +128,7 @@ static inline u32 ice_round_to_num(u32 N, u32 R)
#define ICE_DBG_USER BIT_ULL(31)
#define ICE_DBG_ALL0xULL
-#ifndef __ALWAYS_UNUSED
#define __ALWAYS_UNUSED
-#endif
#define IS_ETHER_ADDR_EQUAL(addr1, addr2) \
(((bool)u16 *)(addr1))[0] == ((u16 *)(addr2))[0]))) && \
--
2.13.6
[dpdk-dev] [PATCH 11/12] net/ice: support 1/10G device IDs
Add support for 1/10G devices.
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_devids.h | 4
drivers/net/ice/ice_ethdev.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ice/base/ice_devids.h
b/drivers/net/ice/base/ice_devids.h
index 348d1907a..46ffdee2d 100644
--- a/drivers/net/ice/base/ice_devids.h
+++ b/drivers/net/ice/base/ice_devids.h
@@ -24,5 +24,9 @@
#define ICE_DEV_ID_C822N_QSFP 0x1891
/* Intel(R) Ethernet Connection C822N for SFP */
#define ICE_DEV_ID_C822N_SFP 0x1892
+/* Intel(R) Ethernet Connection C822N/X557-AT 10GBASE-T */
+#define ICE_DEV_ID_C822N_10G_BASE_T0x1893
+/* Intel(R) Ethernet Connection C822N 1GbE */
+#define ICE_DEV_ID_C822N_SGMII 0x1894
#endif /* _ICE_DEVIDS_H_ */
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index de189daba..5c5feae2a 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -163,6 +163,8 @@ static const struct rte_pci_id pci_id_ice_map[] = {
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_BACKPLANE) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_QSFP) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_SFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_C822N_10G_BASE_T) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_C822N_SGMII) },
{ .vendor_id = 0, /* sentinel */ },
};
--
2.13.6
[dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com
Hi all As described in RFC "[RFC] net: new vdpa PMD for Mellanox devices", a new vdpa drivers is going to be added for Mellanox devices - mlx5_vdpa The only vdpa driver now is the IFC driver that is located in net directory. The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and not the eth_dev ops. All the others drivers in net provide the eth-dev ops. I suggest to create a new class for vdpa drivers, to move IFC to this class and to add the mlx5_vdpa to this class too. Later, all the new drivers that implements the vdpa ops will be added to the vdpa class. Will be nice to see your comments. Matan
[dpdk-dev] [PATCH] net/fm10k: fix descriptor vlan field filling in Tx
The VLAN field in the descriptor is not filled when ol_flags has
no VLAN flag. When the caller sends some packets with VLAN tags,
but other packets do not have VLAN tags, the behavior of the program
cannot be determined.
Fixes: 4b61d3bfa941 ("fm10k: add receive and tranmit")
Cc: jeffrey.b.s...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Lu Qiuwen
---
drivers/net/fm10k/fm10k_rxtx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 5c3112183..4accaa2cd 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -611,6 +611,8 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q,
struct rte_mbuf *mb)
/* set vlan if requested */
if (mb->ol_flags & PKT_TX_VLAN_PKT)
q->hw_ring[q->next_free].vlan = mb->vlan_tci;
+ else
+ q->hw_ring[q->next_free].vlan = 0;
q->sw_ring[q->next_free] = mb;
q->hw_ring[q->next_free].buffer_addr =
--
2.20.1.windows.1
Re: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker image
> -Original Message-
> From: dev On Behalf Of Abdul Halim
> Sent: Tuesday, December 3, 2019 19:42
> To: dev@dpdk.org
> Cc: ray.kinse...@intel.com; yasufu...@gmail.com; Abdul Halim
>
> Subject: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker
> image
>
> Adding a Dockerfile with Ubuntu bionic base image to build dpdk as shared
> library. This docker image could be used as base image to build and run dpdk
> applications in containers.
>
> Signed-off-by: Abdul Halim
>
> ---
>
> v2:
> * renamed Dockerfile name from Dockerfile.ubuntu to Dockerfile.bionic
> * added call to ldconfig to update cache of libraries to include newly
> installed DPDK libs
>
> ---
>
> v3:
> * added example use-case of dpdk dockerfile in extras/README.md
> ---
> extras/Dockerfile.bionic | 40
> +
> extras/README.md | 52
>
> 2 files changed, 92 insertions(+)
> create mode 100644 extras/Dockerfile.bionic create mode 100644
> extras/README.md
>
> diff --git a/extras/Dockerfile.bionic b/extras/Dockerfile.bionic new file mode
> 100644 index 000..f83b720
> --- /dev/null
> +++ b/extras/Dockerfile.bionic
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2019 Intel
> +Corporation FROM ubuntu:bionic
> +
> +# install requirements for getting and building DPDK # including
> +dependencies for DPDK features RUN apt-get update && apt-get install -y
> +\
> +build-essential \
> +pkg-config \
> +python3 \
> +python3-pip \
> +ninja-build \
> +libjansson-dev \
> +libbsd-dev \
> +libnuma-dev \
> +libssl-dev \
> +zlib1g-dev \
> +libpcap-dev \
> +libibverbs-dev \
> +&& pip3 install meson \
> +&& apt-get clean && rm -rf /var/lib/apt/lists/*
> +
> +ADD . /tmp/dpdk
> +
> +WORKDIR /tmp/dpdk
> +
> +RUN meson build \
> +-Ddefault_library=shared \
> +-Dmachine=default \
> +-Dper_library_versions=false \
> +&& ninja -C build install \
> +&& ldconfig \
> +&& cd /; rm -rf /tmp/dpdk
> +
> +WORKDIR /
> +
> +# Installed DPDK Shared library location:
> +# lib dir : /usr/local/lib/
> +# include : /usr/local/include/
> +# pkgconfig file: /usr/local/lib/x86_64-linux-gnu/pkgconfig/libdpdk.pc
> diff --git a/extras/README.md b/extras/README.md new file mode 100644
> index 000..f38d7f1
> --- /dev/null
> +++ b/extras/README.md
> @@ -0,0 +1,52 @@
> +# Build DPDK Docker image
> +
> +To build a docker image run the following command from dpdk root
> directory.
> +
> +```
> +DOCKER_TAG="dpdk"
> +docker build -t ${DOCKER_TAG} -f extras/Dockerfile.bionic .
> +```
> +
> +# Example of how to use this dpdk library image
> +
> +The following steps shows how to use the dpdk shared library container
> +to build and run a dpdk application without having to build dpdk
> +library for each application.
> +
> +## Create a dpdk sample app docker file with 'dpdk' as the base image
> +
> +Create a docker file to build the dpdk helloworld application. Since,
> +we are creating a docker file for dpdk helloworld app we need to add
> +the dpdk source files, thus create the following docker file in dpdk root
> directory.
> +
> +```
> +cat << EOF > Dockerfile.dpdkSampleApp
> +FROM dpdk
> +
> +ADD . /opt/dpdk
> +
> +WORKDIR /opt/dpdk/examples/helloworld
> +RUN make && cp build/helloworld-shared /usr/local/bin/helloworld EOF
> +```
> +
> +## Build sample app docker image
> +
> +```
> +DOCKERAPP_TAG="dpdk-helloworld"
> +docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
> +```
Hi Abdul,
I tried the steps on AArch64 platform, and hit error as below:
$ sudo docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
Sending build context to Docker daemon 2.55GB
Step 1/4 : FROM dpdk
---> 955448007987
Step 2/4 : ADD . /opt/dpdk
---> d8b58019a7e2
Step 3/4 : WORKDIR /opt/dpdk/examples/helloworld
---> Running in 14fc89f7d3cd
Removing intermediate container 14fc89f7d3cd
---> 065a682c58fd
Step 4/4 : RUN make && cp build/helloworld-shared /usr/local/bin/helloworld
---> Running in 11e755a7180b
Makefile:44: *** "Please define RTE_SDK environment variable". Stop.
The command '/bin/sh -c make && cp build/helloworld-shared
/usr/local/bin/helloworld' returned a non-zero code: 2
Missing define of RTE_SDK and RTE_TARGET?
> +
> +This sample app now can be run like any other applicaiton in a docker
> container.
> +
> +```
> +$ docker run --rm -it -v /dev/hugepages:/dev/hugepages dpdk-helloworld
> +```
> +
> +## Running the sample app
> +Once inside the container run helloword binary
> +
> +```
> +$ root@11233ed2e69c # helloworld
> +```
> +
> --
> 1.8.3.1
>
> --
> Intel Research and Development Ireland Limited Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachment
[dpdk-dev] DPDK Release Status Meeting 5/12/2019
Minutes 5 December 2019 --- Agenda: * Release Dates * 19.11 feedback * Subtrees * OvS Participants: * Arm * Debian/Microsoft * Intel * Mellanox * NXP * Red Hat Release Dates - * v19.11 is released on Friday, 29 November v19.11 is latest LTS and will be supported next two years. * https://mails.dpdk.org/archives/dev/2019-November/152519.html * https://core.dpdk.org/download/ * https://doc.dpdk.org/guides/rel_notes/release_19_11.html * v20.02 dates: * Proposal/V1:Wednesday 11 December 2019 * Integration/Merge/RC1: Wednesday 15 January 2020 * Release:Friday 14 February 2020 * Reminder for 20.02 roadmaps from contributors, non received yet. 19.11 feedback -- * Gavin reported a performance drop on specific NICs with v19.11, will report the issue via Bugzilla. Subtrees * main * Build issue in the main repo solved * next-net * Nothing much in both backlog and the repo yet * 'ionic' PMD reviewed, got confirmation that it will be re-licensed as BSD-3 * next-net-crypto * add eventmode to ipsec-secgw patchset is in the backlog * There is a request to have release notes template ready for next releases so that patches addressing those releases can update them * This can be confusing for release packages, to have release notes from future releases, so they won't be included. * Need to clarify CPU crypto patchset status, if it requires ABI breakage, it may need to wait for next LTS * next-net-eventdev * l3fwd eventdev support patches are in backlog * WANTED: l3fwd sample app is missing maintainer, we need volunteers for maintaining and/or reviewing it. * next-net-virtio * dynamic logging patch is in the queue * Will work on virtio vdpa driver * Should we move vdpa related code to a common folder? * LTS * 17.11.10 * Luca is working on it with best effort, planning a release on December * This will be last 17.11.x release * 18.11.6 * Kevin already backported some patches and sent notification emails for it * ~150 more patches waiting for the backporting * For the patches that failed to backport automatically, emails sent to authors and mail list to request help from authors for backporting. * Is this method working or if we can find more effective way. OvS --- * DPDK 19.11 support upstreamed on 'master' branch * Next week there will be OvS conference: http://www.openvswitch.org/support/ovscon2019/ 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.
Re: [dpdk-dev] [PATCH] test/common: fix log2 check
David Marchand writes:
> On Wed, Dec 4, 2019 at 10:20 PM Aaron Conole wrote:
>>
>> David Marchand writes:
>>
>> > We recently started to get random failures on the common_autotest ut with
>> > clang on Ubuntu 16.04.6.
>> >
>> > Example: https://travis-ci.com/DPDK/dpdk/jobs/263177424
>> >
>> > Wrong rte_log2_u64(0) val 0, expected
>> > Test Failed
>> >
>> > The ut passes 0 to log2() to get an expected value.
>> >
>> > Quoting log2 / log(3) manual:
>> > If x is zero, then a pole error occurs, and the functions return
>> > -HUGE_VAL, -HUGE_VALF, or -HUGE_VALL, respectively.
>> >
>> > rte_log2_uXX helpers handle 0 as a special value and return 0.
>> > Let's have dedicated tests for this case.
>> >
>> > Fixes: 05c4345ef5c2 ("test: add unit test for integer log2 function")
>> > Cc: sta...@dpdk.org
>> >
>> > Signed-off-by: David Marchand
>> > ---
>>
>> Acked-by: Aaron Conole
>>
>> Somethings that concern me:
>>
>> 1. A log2(0) should probably be an undetermined value, but this
>> effectively makes log2(0) == log2(1) so that if anyone uses these
>> for some mathematical work, it will have an exceptional behavior. I
>> know it's documented from a programmer perspective, but I am all for
>> documenting the mathematical side effect as well.
>
> What do you have in mind, adding a big warning in the doxygen "THIS IS
> NOT REAL MATH STUFF" ? :-)
Is such a warning not reasonable? :-)
>>
>> 2. Why hasn't this been complaining for so long? Or has it and we just
>> haven't noticed? Were some compiler flags changed recently? (maybe
>> -funsafe-math was always set or something?)
>
> Yes, I wondered too how we did not see this earlier.
> Even now, it happens randomly.
>
> libc log2(0) is not undefined itself, it returns -infinity.
> Looking at the test code, ceilf (I would expect ceil) returns
> -infinity when getting it passed.
> So I'd say the problem lies in the cast to uint32_t.
>
> Both gcc and clang do not seem to bother with standard compilation
> flags, and the cast gives 0 on my RHEL.
>
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> printf("%lf %f %"PRIu32"\n", log2(0), (float)log2(0), (uint32_t)log2(0));
> return 0;
> }
>
> $ ./log2
> -inf -inf 0
>
>
> Now, if I use UBSAN with clang, I get a complaint at runtime:
> $ ./log2
> (/home/dmarchan/log2+0x41dfa5): runtime error: value -inf is outside
> the range of representable values of type 'unsigned int'
> -inf -inf 0
>
> Not sure if it explains the random failures, but won't undefined
> behavior eat your babies?
Possibly. I would still expect it to be consistent when it eats babies,
but maybe it doesn't have to be.
[dpdk-dev] [PATCH 1/4] lib/crypto: add support for EC Point Multiplication
From: Balakrishna Bhamidipati
Elliptic Curve Point Multiplication xform type and op
parameters are added.
Signed-off-by: Anoob Joseph
Signed-off-by: Balakrishna Bhamidipati
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/default.ini | 1 +
lib/librte_cryptodev/rte_crypto_asym.h | 17 +
lib/librte_cryptodev/rte_cryptodev.c | 1 +
3 files changed, 19 insertions(+)
diff --git a/doc/guides/cryptodevs/features/default.ini
b/doc/guides/cryptodevs/features/default.ini
index 2f6c785..3a54b07 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -109,3 +109,4 @@ Modular Exponentiation =
Modular Inversion =
Diffie-hellman =
ECDSA =
+EC Point Multiplication =
diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
b/lib/librte_cryptodev/rte_crypto_asym.h
index dd5e6e3..b98ce6c 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -85,6 +85,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
+ RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL,
+ /**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
/**< End of list */
};
@@ -598,6 +600,20 @@ struct rte_crypto_ecdsa_op_param {
};
/**
+ * Structure for EC point operation param
+ */
+struct rte_crypto_ec_point_mul_param {
+ struct rte_crypto_ec_point p;
+ /**< x and y coordinates of input point */
+
+ struct rte_crypto_ec_point r;
+ /**< x and y coordinates of resultant point */
+
+ rte_crypto_param scalar;
+ /**< Scalar to multiply the input point */
+};
+
+/**
* Asymmetric Cryptographic Operation.
*
* Structure describing asymmetric crypto operation params.
@@ -620,6 +636,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_dh_op_param dh;
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
+ struct rte_crypto_ec_point_mul_param ecpm;
};
};
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index 0d6babb..eea57c6 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -174,6 +174,7 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
[RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
[RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
+ [RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL]= "ecpm",
};
/**
--
2.7.4
[dpdk-dev] [PATCH 0/4] add ECPM support
This series adds support for ECPM (Elliptic Curve Point Multiplication) asymmetric operations. Library changes and PMD changes for crypto_octeontx & crypto_octeontx2 is added. The final patch adds the required test vectors and verification routines. Balakrishna Bhamidipati (1): lib/crypto: add support for EC Point Multiplication Sunila Sahu (3): crypto/octeontx: add EC Point Mul support crypto/octeontx2: add EC Point Mul support app/test: add EC point multiplication test app/test/test_cryptodev_asym.c | 177 +++ app/test/test_cryptodev_asym_util.h| 11 + app/test/test_cryptodev_ecpm_test_vectors.h| 353 + doc/guides/cryptodevs/features/default.ini | 1 + doc/guides/cryptodevs/features/octeontx.ini| 1 + doc/guides/cryptodevs/features/octeontx2.ini | 1 + drivers/common/cpt/cpt_mcode_defines.h | 2 + drivers/common/cpt/cpt_ucode_asym.h| 85 + .../crypto/octeontx/otx_cryptodev_capabilities.c | 11 + drivers/crypto/octeontx/otx_cryptodev_ops.c| 23 ++ .../crypto/octeontx2/otx2_cryptodev_capabilities.c | 11 + drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 22 ++ lib/librte_cryptodev/rte_crypto_asym.h | 17 + lib/librte_cryptodev/rte_cryptodev.c | 1 + 14 files changed, 716 insertions(+) create mode 100644 app/test/test_cryptodev_ecpm_test_vectors.h -- 2.7.4
[dpdk-dev] [PATCH 4/4] app/test: add EC point multiplication test
From: Sunila Sahu
Adding EC point multiplication test vectors and verify routines.
Signed-off-by: Anoob Joseph
Signed-off-by: Sunila Sahu
---
app/test/test_cryptodev_asym.c | 177 ++
app/test/test_cryptodev_asym_util.h | 11 +
app/test/test_cryptodev_ecpm_test_vectors.h | 353
3 files changed, 541 insertions(+)
create mode 100644 app/test/test_cryptodev_ecpm_test_vectors.h
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index b913a7d..b6d96d6 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -19,6 +19,7 @@
#include "test_cryptodev_dh_test_vectors.h"
#include "test_cryptodev_dsa_test_vectors.h"
#include "test_cryptodev_ecdsa_test_vectors.h"
+#include "test_cryptodev_ecpm_test_vectors.h"
#include "test_cryptodev_mod_test_vectors.h"
#include "test_cryptodev_rsa_test_vectors.h"
#include "test_cryptodev_asym_util.h"
@@ -1044,6 +1045,7 @@ static inline void print_asym_capa(
capa->modlen.increment);
break;
case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+ case RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL:
default:
break;
}
@@ -2108,6 +2110,179 @@ test_ecdsa_sign_verify_all_curve(void)
return overall_status;
}
+static int
+test_ec_point_mul(enum curve curve_id)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ struct rte_mempool *sess_mpool = ts_params->session_mpool;
+ struct rte_mempool *op_mpool = ts_params->op_mpool;
+ struct crypto_testsuite_ecpm_params input_params;
+ struct rte_cryptodev_asym_session *sess = NULL;
+ uint8_t dev_id = ts_params->valid_devs[0];
+ struct rte_crypto_op *result_op = NULL;
+ uint8_t output_buf_x[TEST_DATA_SIZE];
+ uint8_t output_buf_y[TEST_DATA_SIZE];
+ struct rte_crypto_asym_xform xform;
+ struct rte_crypto_asym_op *asym_op;
+ struct rte_cryptodev_info dev_info;
+ struct rte_crypto_op *op = NULL;
+ int status = TEST_SUCCESS, ret;
+
+ switch (curve_id) {
+ case P192:
+ input_params = ecpm_param_p192;
+ break;
+ case P224:
+ input_params = ecpm_param_p224;
+ break;
+ case P256:
+ input_params = ecpm_param_p256;
+ break;
+ case P384:
+ input_params = ecpm_param_p384;
+ break;
+ case P521:
+ input_params = ecpm_param_p521;
+ break;
+ default:
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Unsupported curve id\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ rte_cryptodev_info_get(dev_id, &dev_info);
+
+ sess = rte_cryptodev_asym_session_create(sess_mpool);
+ if (sess == NULL) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Session creation failed\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ /* Setup crypto op data structure */
+ op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
+ if (op == NULL) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Failed to allocate asymmetric crypto "
+ "operation struct\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+ asym_op = op->asym;
+
+ /* Setup asym xform */
+ xform.next = NULL;
+ xform.xform_type = RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL;
+ xform.ec.curve_id = input_params.curve;
+
+ if (rte_cryptodev_asym_session_init(dev_id, sess, &xform,
+ sess_mpool) < 0) {
+ RTE_LOG(ERR, USER1,
+ "line %u FAILED: %s", __LINE__,
+ "Unable to config asym session\n");
+ status = TEST_FAILED;
+ goto exit;
+ }
+
+ /* Attach asymmetric crypto session to crypto operations */
+ rte_crypto_op_attach_asym_session(op, sess);
+
+ /* Populate op with operational details */
+ op->asym->ecpm.p.x.data = input_params.gen_x.data;
+ op->asym->ecpm.p.x.length = input_params.gen_x.length;
+ op->asym->ecpm.p.y.data = input_params.gen_y.data;
+ op->asym->ecpm.p.y.length = input_params.gen_y.length;
+ op->asym->ecpm.scalar.data = input_params.privkey.data;
+ op->asym->ecpm.scalar.length = input_params.privkey.length;
+
+ /* Init out buf */
+ op->asym->ecpm.r.x.data = output_buf_x;
+ op->asym->ecpm.r.y.data = output_buf_y;
+
+ RTE_LOG(DEBUG, USER1, "Proce
[dpdk-dev] [PATCH 2/4] crypto/octeontx: add EC Point Mul support
From: Sunila Sahu
Adding support for EC Point Multiplication operation in crypto_octeontx
PMD.
Signed-off-by: Anoob Joseph
Signed-off-by: Balakrishna Bhamidipati
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/octeontx.ini| 1 +
drivers/common/cpt/cpt_mcode_defines.h | 2 +
drivers/common/cpt/cpt_ucode_asym.h| 85 ++
.../crypto/octeontx/otx_cryptodev_capabilities.c | 11 +++
drivers/crypto/octeontx/otx_cryptodev_ops.c| 23 ++
5 files changed, 122 insertions(+)
diff --git a/doc/guides/cryptodevs/features/octeontx.ini
b/doc/guides/cryptodevs/features/octeontx.ini
index 544bb46..3cc807a 100644
--- a/doc/guides/cryptodevs/features/octeontx.ini
+++ b/doc/guides/cryptodevs/features/octeontx.ini
@@ -73,3 +73,4 @@ Modular Exponentiation = Y
Modular Inversion =
Diffie-hellman =
ECDSA = Y
+EC Point Multiplication = Y
diff --git a/drivers/common/cpt/cpt_mcode_defines.h
b/drivers/common/cpt/cpt_mcode_defines.h
index 64d3e8c..d830bef 100644
--- a/drivers/common/cpt/cpt_mcode_defines.h
+++ b/drivers/common/cpt/cpt_mcode_defines.h
@@ -24,6 +24,7 @@
/* AE opcodes */
#define CPT_MAJOR_OP_MODEX 0x03
#define CPT_MAJOR_OP_ECDSA 0x04
+#define CPT_MAJOR_OP_ECC 0x05
#define CPT_MINOR_OP_MODEX 0x01
#define CPT_MINOR_OP_PKCS_ENC 0x02
#define CPT_MINOR_OP_PKCS_ENC_CRT 0x03
@@ -32,6 +33,7 @@
#define CPT_MINOR_OP_MODEX_CRT 0x06
#define CPT_MINOR_OP_ECDSA_SIGN0x01
#define CPT_MINOR_OP_ECDSA_VERIFY 0x02
+#define CPT_MINOR_OP_ECC_UMP 0x03
#define CPT_BLOCK_TYPE1 0
#define CPT_BLOCK_TYPE2 1
diff --git a/drivers/common/cpt/cpt_ucode_asym.h
b/drivers/common/cpt/cpt_ucode_asym.h
index 1f76bd1..9a54d34 100644
--- a/drivers/common/cpt/cpt_ucode_asym.h
+++ b/drivers/common/cpt/cpt_ucode_asym.h
@@ -172,6 +172,8 @@ cpt_fill_asym_session_parameters(struct cpt_asym_sess_misc
*sess,
ret = cpt_fill_modex_params(sess, xform);
break;
case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+ /* Fall through */
+ case RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL:
ret = cpt_fill_ec_params(sess, xform);
break;
default:
@@ -199,6 +201,8 @@ cpt_free_asym_session_parameters(struct cpt_asym_sess_misc
*sess)
rte_free(mod->modulus.data);
break;
case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+ /* Fall through */
+ case RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL:
break;
default:
CPT_LOG_DP_ERR("Invalid transform type");
@@ -828,4 +832,85 @@ cpt_enqueue_ecdsa_op(struct rte_crypto_op *op,
return 0;
}
+static __rte_always_inline int
+cpt_ecpm_prep(struct rte_crypto_ec_point_mul_param *ecpm,
+ struct asym_op_params *asym_params,
+ uint8_t curveid)
+{
+ struct cpt_request_info *req = asym_params->req;
+ phys_addr_t mphys = asym_params->meta_buf;
+ uint16_t x1_len = ecpm->p.x.length;
+ uint16_t y1_len = ecpm->p.y.length;
+ uint16_t scalar_align, p_align;
+ uint16_t dlen, rlen, prime_len;
+ uint16_t x1_offset, y1_offset;
+ vq_cmd_word0_t vq_cmd_w0;
+ opcode_info_t opcode;
+ buf_ptr_t caddr;
+ uint8_t *dptr;
+
+ prime_len = ec_grp[curveid].prime.length;
+
+ /* Input buffer */
+ dptr = RTE_PTR_ADD(req, sizeof(struct cpt_request_info));
+
+ p_align = ROUNDUP8(prime_len);
+ scalar_align = ROUNDUP8(ecpm->scalar.length);
+
+ /*
+* Set dlen = sum(ROUNDUP8(input point(x and y coordinates), prime,
+* scalar length),
+* Please note point length is equivalent to prime of the curve
+*/
+ dlen = 3 * p_align + scalar_align;
+
+ x1_offset = prime_len - x1_len;
+ y1_offset = prime_len - y1_len;
+
+ memset(dptr, 0, dlen);
+
+ /* Copy input point, scalar, prime */
+ memcpy(dptr + x1_offset, ecpm->p.x.data, x1_len);
+ dptr += p_align;
+ memcpy(dptr + y1_offset, ecpm->p.y.data, y1_len);
+ dptr += p_align;
+ memcpy(dptr, ecpm->scalar.data, ecpm->scalar.length);
+ dptr += scalar_align;
+ memcpy(dptr, ec_grp[curveid].prime.data, ec_grp[curveid].prime.length);
+ dptr += p_align;
+
+ /* Setup opcodes */
+ opcode.s.major = CPT_MAJOR_OP_ECC;
+ opcode.s.minor = CPT_MINOR_OP_ECC_UMP;
+
+ /* GP op header */
+ vq_cmd_w0.s.opcode = opcode.flags;
+ vq_cmd_w0.s.param1 = curveid;
+ vq_cmd_w0.s.param2 = ecpm->scalar.length;
+ vq_cmd_w0.s.dlen = dlen;
+ vq_cmd_w0.u64 = vq_cmd_w0.u64;
+
+ /* Filling cpt_request_info structure */
+ req->ist.ei0 = vq_cmd_w0.u64;
+ req->ist.ei1 = mphys;
+ req->ist.ei2 = mphys + dlen;
+
+ /* Result buffer will store output point where length of
+* each coordinate will be of prime length, thus set
+* r
[dpdk-dev] [PATCH 3/4] crypto/octeontx2: add EC Point Mul support
From: Sunila Sahu
Adding support for EC Point MUltiplication operation in crypto_octeontx2
PMD.
Signed-off-by: Anoob Joseph
Signed-off-by: Balakrishna Bhamidipati
Signed-off-by: Sunila Sahu
---
doc/guides/cryptodevs/features/octeontx2.ini | 1 +
.../crypto/octeontx2/otx2_cryptodev_capabilities.c | 11 +++
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 22 ++
3 files changed, 34 insertions(+)
diff --git a/doc/guides/cryptodevs/features/octeontx2.ini
b/doc/guides/cryptodevs/features/octeontx2.ini
index dd6369b..f1625c4 100644
--- a/doc/guides/cryptodevs/features/octeontx2.ini
+++ b/doc/guides/cryptodevs/features/octeontx2.ini
@@ -73,3 +73,4 @@ Modular Exponentiation = Y
Modular Inversion =
Diffie-hellman =
ECDSA = Y
+EC Point Multiplication = Y
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
b/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
index f2079e2..d1c9c80 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_capabilities.c
@@ -639,6 +639,17 @@ rte_cryptodev_capabilities otx2_cpt_capabilities[] = {
},
}
},
+ { /* EC POINT MUL */
+ .op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
+ {.asym = {
+ .xform_capa = {
+ .xform_type =
+ RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL,
+ .op_types = 0
+ }
+ },
+ }
+ },
/* End of asymmetric capabilities */
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
};
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 17c755d..574873a 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -447,6 +447,12 @@ otx2_cpt_enqueue_asym(struct otx2_cpt_qp *qp,
if (unlikely(ret))
goto req_fail;
break;
+ case RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL:
+ ret = cpt_ecpm_prep(&asym_op->ecpm, ¶ms,
+ sess->ec_ctx.curveid);
+ if (unlikely(ret))
+ goto req_fail;
+ break;
default:
op->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
ret = -EINVAL;
@@ -665,6 +671,19 @@ otx2_cpt_asym_dequeue_ecdsa_op(struct
rte_crypto_ecdsa_op_param *ecdsa,
ecdsa->s.length = prime_len;
}
+static __rte_always_inline void
+otx2_cpt_asym_dequeue_ecpm_op(struct rte_crypto_ec_point_mul_param *ecpm,
+struct cpt_request_info *req,
+struct cpt_asym_ec_ctx *ec)
+{
+ int prime_len = ec_grp[ec->curveid].prime.length;
+
+ memcpy(ecpm->r.x.data, req->rptr, prime_len);
+ memcpy(ecpm->r.y.data, req->rptr + ROUNDUP8(prime_len), prime_len);
+ ecpm->r.x.length = prime_len;
+ ecpm->r.y.length = prime_len;
+}
+
static void
otx2_cpt_asym_post_process(struct rte_crypto_op *cop,
struct cpt_request_info *req)
@@ -687,6 +706,9 @@ otx2_cpt_asym_post_process(struct rte_crypto_op *cop,
case RTE_CRYPTO_ASYM_XFORM_ECDSA:
otx2_cpt_asym_dequeue_ecdsa_op(&op->ecdsa, req, &sess->ec_ctx);
break;
+ case RTE_CRYPTO_ASYM_XFORM_EC_POINT_MUL:
+ otx2_cpt_asym_dequeue_ecpm_op(&op->ecpm, req, &sess->ec_ctx);
+ break;
default:
CPT_LOG_DP_DEBUG("Invalid crypto xform type");
cop->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
--
2.7.4
[dpdk-dev] [PATCH] latencystats: fix latency calculation for multithread
Make latency calculation multithread safe by
using spinlock.
Fixes: 5cd3cac9ed ("latency: added new library for latency stats")
Cc: sta...@dpdk.org
Signed-off-by: reshma pattan
---
lib/librte_latencystats/rte_latencystats.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_latencystats/rte_latencystats.c
b/lib/librte_latencystats/rte_latencystats.c
index 98e018939..ba2fff3bc 100644
--- a/lib/librte_latencystats/rte_latencystats.c
+++ b/lib/librte_latencystats/rte_latencystats.c
@@ -42,6 +42,7 @@ struct rte_latency_stats {
float avg_latency; /**< Average latency in nano seconds */
float max_latency; /**< Maximum latency in nano seconds */
float jitter; /** Latency variation */
+ rte_spinlock_t lock; /** Latency calculation lock */
};
static struct rte_latency_stats *glob_stats;
@@ -164,6 +165,7 @@ calc_latency(uint16_t pid __rte_unused,
latency[cnt++] = now - pkts[i]->timestamp;
}
+ rte_spinlock_lock(&glob_stats->lock);
for (i = 0; i < cnt; i++) {
/*
* The jitter is calculated as statistical mean of interpacket
@@ -193,6 +195,7 @@ calc_latency(uint16_t pid __rte_unused,
alpha * (latency[i] - glob_stats->avg_latency);
prev_latency = latency[i];
}
+ rte_spinlock_unlock(&glob_stats->lock);
return nb_pkts;
}
@@ -223,6 +226,7 @@ rte_latencystats_init(uint64_t app_samp_intvl,
}
glob_stats = mz->addr;
+ rte_spinlock_init(&glob_stats->lock);
samp_intvl = app_samp_intvl * latencystat_cycles_per_ns();
/** Register latency stats with stats library */
--
2.21.0
[dpdk-dev] [RFC 1/6] process-info: introduce process-info library
From: Bruce Richardson
This patch introduces the process_info library. The library does socket
and connection management on a local unix socket, and allows the calling
of callback functions on receipt of a message from a connected client.
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
The library is not yet initialised to run, this will come in a later
patch integrating with the EAL library.
---
config/common_base| 5 +
lib/Makefile | 1 +
lib/librte_process_info/Makefile | 26 ++
lib/librte_process_info/meson.build | 8 +
lib/librte_process_info/process_info.c| 231 ++
lib/librte_process_info/rte_process_info.h| 25 ++
.../rte_process_info_version.map | 6 +
lib/meson.build | 1 +
mk/rte.app.mk | 1 +
9 files changed, 304 insertions(+)
create mode 100644 lib/librte_process_info/Makefile
create mode 100644 lib/librte_process_info/meson.build
create mode 100644 lib/librte_process_info/process_info.c
create mode 100644 lib/librte_process_info/rte_process_info.h
create mode 100644 lib/librte_process_info/rte_process_info_version.map
diff --git a/config/common_base b/config/common_base
index 7dec7ed45..5f49b934f 100644
--- a/config/common_base
+++ b/config/common_base
@@ -1093,3 +1093,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
# Compile the eventdev application
#
CONFIG_RTE_APP_EVENTDEV=y
+
+#
+# Compile the process_info library
+#
+CONFIG_RTE_LIBRTE_PROCESS_INFO=y
diff --git a/lib/Makefile b/lib/Makefile
index 46b91ae1a..466cd04ef 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -4,6 +4,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
DIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += librte_kvargs
+DIRS-$(CONFIG_RTE_LIBRTE_PROCESS_INFO) += librte_process_info
DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
DEPDIRS-librte_eal := librte_kvargs
DIRS-$(CONFIG_RTE_LIBRTE_PCI) += librte_pci
diff --git a/lib/librte_process_info/Makefile b/lib/librte_process_info/Makefile
new file mode 100644
index 0..67b9a9f20
--- /dev/null
+++ b/lib/librte_process_info/Makefile
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2019 Intel Corporation
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_process_info.a
+
+CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include/arch/$(ARCH_DIR)/
+CFLAGS += -pthread
+LDLIBS += -pthread
+
+EXPORT_MAP := rte_process_info_version.map
+
+LIBABIVER := 1
+
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) := process_info.c
+
+# install includes
+INCS := rte_process_info.h
+SYMLINK-y-include := $(INCS)
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_process_info/meson.build
b/lib/librte_process_info/meson.build
new file mode 100644
index 0..42850e816
--- /dev/null
+++ b/lib/librte_process_info/meson.build
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+includes = [global_inc]
+includes += include_directories('../librte_eal/common/include/arch/' +
arch_subdir)
+
+sources = files('process_info.c')
+headers = files('rte_process_info.h')
diff --git a/lib/librte_process_info/process_info.c
b/lib/librte_process_info/process_info.c
new file mode 100644
index 0..3959e24fa
--- /dev/null
+++ b/lib/librte_process_info/process_info.c
@@ -0,0 +1,231 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "rte_process_info.h"
+
+#define MAX_CMD_LEN 56
+
+static int
+list_commands(const char *cmd __rte_unused, const char *params __rte_unused,
+ char *buffer, int buf_len);
+
+struct cmd_callback {
+ char cmd[MAX_CMD_LEN];
+ process_info_cb fn;
+};
+
+static int sock = -1;
+static struct sockaddr_un sun;
+static char process_info_log_error[1024];
+static struct cmd_callback callbacks[PROCESS_INFO_MAX_CALLBACKS] = {
+ { .cmd = "/", .fn = list_commands },
+};
+static int num_callbacks = 1;
+static rte_spinlock_t callback_sl = RTE_SPINLOCK_INITIALIZER;
+
+/* we won't link against libbsd, so just always use DPDKs-specific version */
+#ifndef strlcpy
+#define strlcpy rte_strlcpy
+#endif
+
+int
+rte_process_info_register(const char *cmd, process_info_cb fn)
+{
+ int i = 0;
+
+ if (strlen(cmd) >= MAX_CMD_LEN || fn == NULL)
+ return -EINVAL;
+ if (num_callbacks >= PROCESS_INFO_MAX_CALLBACKS)
+ return -ENOENT;
+ if (cmd[0] != '/')
+ return -EINVAL;
+
+ rte_spinlock_lock(&callback_sl);
+ while (i < num_callbacks && strcmp(cmd, callbacks[i].cmd) > 0)
+ i++;
+ if (i != num_callbacks)
+ memmove(callbacks
[dpdk-dev] [RFC 2/6] eal: integrate process-info library
From: Bruce Richardson
Integrate the process info library into the EAL.
- Initialize the process-info library as part of EAL init.
This can be disabled using an EAL parameter.
- Register commands to provide some basic info from EAL.
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
lib/Makefile | 2 +-
lib/librte_eal/common/eal_common_options.c | 75 ++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 5 ++
lib/librte_eal/freebsd/eal/Makefile| 1 +
lib/librte_eal/freebsd/eal/eal.c | 14
lib/librte_eal/linux/eal/Makefile | 1 +
lib/librte_eal/linux/eal/eal.c | 15 +
lib/librte_eal/meson.build | 2 +-
9 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index 466cd04ef..cc61176da 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
DIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += librte_kvargs
DIRS-$(CONFIG_RTE_LIBRTE_PROCESS_INFO) += librte_process_info
DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
-DEPDIRS-librte_eal := librte_kvargs
+DEPDIRS-librte_eal := librte_kvargs librte_process_info
DIRS-$(CONFIG_RTE_LIBRTE_PCI) += librte_pci
DEPDIRS-librte_pci := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index a7f9c5f9b..0839a523d 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "eal_internal_cfg.h"
#include "eal_options.h"
@@ -82,6 +83,7 @@ eal_long_options[] = {
{OPT_LEGACY_MEM,0, NULL, OPT_LEGACY_MEM_NUM },
{OPT_SINGLE_FILE_SEGMENTS, 0, NULL, OPT_SINGLE_FILE_SEGMENTS_NUM},
{OPT_MATCH_ALLOCATIONS, 0, NULL, OPT_MATCH_ALLOCATIONS_NUM},
+ {OPT_NO_PROCESS_INFO, 0, NULL, OPT_NO_PROCESS_INFO_NUM },
{0, 0, NULL, 0}
};
@@ -126,6 +128,75 @@ static int master_lcore_parsed;
static int mem_parsed;
static int core_parsed;
+static char **eal_args;
+static char **eal_app_args;
+
+#define EAL_PARAM_REQ "/eal:params"
+#define EAL_APP_PARAM_REQ "/eal:app_params"
+
+/* callback handler for process_info library to report out EAL flags */
+int
+handle_eal_info_request(const char *cmd, const char *params __rte_unused,
+ char *buffer, int buf_len)
+{
+ char **args;
+ int used = 0;
+ int i = 0;
+
+ if (strcmp(cmd, EAL_PARAM_REQ) == 0)
+ args = eal_args;
+ else if (strcmp(cmd, EAL_APP_PARAM_REQ) == 0)
+ args = eal_app_args;
+ else /* version */
+ return snprintf(buffer, buf_len, "\"%s\"", rte_version());
+
+ if (args == NULL || args[0] == NULL)
+ return snprintf(buffer, buf_len, "[]"); /* empty list */
+
+ used = strlcpy(buffer, "[", buf_len);
+ while (args[i] != NULL)
+ used += snprintf(buffer + used, buf_len - used, "\"%s\",",
+ args[i++]);
+ buffer[used - 1] = ']';
+ return used;
+}
+
+int
+eal_save_args(int argc, char **argv)
+{
+ int i, j;
+
+ /* clone argv to report out later. We overprovision, but
+* this does not waste huge amounts of memory
+*/
+ eal_args = calloc(argc + 1, sizeof(*eal_args));
+ if (eal_args == NULL)
+ return -1;
+
+ for (i = 0; i < argc; i++) {
+ eal_args[i] = strdup(argv[i]);
+ if (strcmp(argv[i], "--") == 0)
+ break;
+ }
+ eal_args[i++] = NULL; /* always finish with NULL */
+ rte_process_info_register(EAL_PARAM_REQ, handle_eal_info_request);
+
+ /* allow reporting of any app args we know about too */
+ if (i == argc)
+ return 0;
+
+ eal_app_args = calloc(argc - i + 1, sizeof(*eal_args));
+ if (eal_app_args == NULL)
+ return -1;
+
+ for (j = 0; i < argc; j++, i++)
+ eal_app_args[j] = strdup(argv[i]);
+ eal_app_args[j] = NULL;
+ rte_process_info_register(EAL_APP_PARAM_REQ, handle_eal_info_request);
+
+ return 0;
+}
+
static int
eal_option_device_add(enum rte_devtype type, const char *optarg)
{
@@ -1446,6 +1517,9 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
+ case OPT_NO_PROCESS_INFO_NUM:
+ conf->no_process_info = 1;
+ break;
/* don't know what to do, leave this to caller */
default:
@@ -1687,6 +1761,7 @@ eal_common_usage(void)
" --"OPT_IN_MEMORY" Operate entirely in memory. This will\n"
" disable secondary process support\n
[dpdk-dev] [RFC 4/6] ethdev: add callback support for process-info
From: Bruce Richardson
The ethdev library now registers commands with process_info, and
implements the callback functions. These commands allow the list of
ethdev ports and the stats for a port to be queried.
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/rte_ethdev.c | 73 ++
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index b627e4e23..f586f83de 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -12,7 +12,7 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_meter
+LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_meter -lrte_process_info
EXPORT_MAP := rte_ethdev_version.map
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 6e9cb243e..b0b5ceec5 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "rte_ethdev.h"
#include "rte_ethdev_driver.h"
@@ -5190,9 +5191,81 @@ rte_eth_devargs_parse(const char *dargs, struct
rte_eth_devargs *eth_da)
return result;
}
+static int
+handle_port_list(const char *cmd __rte_unused,
+ const char *params __rte_unused,
+ char *buffer, int buf_len)
+{
+ int used = 0;
+ int port_id;
+
+ used = strlcpy(buffer, "[", buf_len);
+ RTE_ETH_FOREACH_DEV(port_id)
+ used += snprintf(buffer + used, buf_len - used, "%d,", port_id);
+ buffer[used - 1] = ']';
+ return used;
+}
+
+static int
+handle_port_stats(const char *cmd __rte_unused,
+ const char *params,
+ char *buffer, int buf_len)
+{
+ struct rte_eth_xstat *eth_xstats;
+ struct rte_eth_xstat_name *xstat_names;
+ int port_id, num_xstats;
+ int i, ret;
+ int used = 0;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ port_id = atoi(params);
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -1;
+
+ used = strlcpy(buffer, "{", buf_len);
+
+ num_xstats = rte_eth_xstats_get(port_id, NULL, 0);
+ if (num_xstats < 0)
+ return -1;
+
+ /* use one malloc for both names and stats */
+ eth_xstats = malloc((sizeof(struct rte_eth_xstat) +
+ sizeof(struct rte_eth_xstat_name)) * num_xstats);
+ if (eth_xstats == NULL)
+ return -1;
+ xstat_names = (void *)ð_xstats[num_xstats];
+
+ ret = rte_eth_xstats_get_names(port_id, xstat_names, num_xstats);
+ if (ret < 0 || ret > num_xstats) {
+ free(eth_xstats);
+ return -1;
+ }
+
+ ret = rte_eth_xstats_get(port_id, eth_xstats, num_xstats);
+ if (ret < 0 || ret > num_xstats) {
+ free(eth_xstats);
+ return -1;
+ }
+
+ for (i = 0; i < num_xstats; i++) {
+ ret = snprintf(buffer + used, buf_len - used,
"\"%s\":%"PRIu64",",
+ xstat_names[i].name, eth_xstats[i].value);
+ if (ret + used >= buf_len)
+ break;
+ used += ret;
+ }
+
+ buffer[used - 1] = '}';
+ return used;
+}
+
RTE_INIT(ethdev_init_log)
{
rte_eth_dev_logtype = rte_log_register("lib.ethdev");
if (rte_eth_dev_logtype >= 0)
rte_log_set_level(rte_eth_dev_logtype, RTE_LOG_INFO);
+ rte_process_info_register("/ethdev:list", handle_port_list);
+ rte_process_info_register("/ethdev:stats", handle_port_stats);
}
--
2.17.1
[dpdk-dev] [RFC 3/6] usertools: add process-info python script
From: Bruce Richardson
This patch adds a python script that can be used with the process_info
library. It connects as a client to the process_info socket, and allows
the user send a command and see the JSON response.
The example usage below shows the script connecting to the process_info
socket, and sending two basic commands entered by the user. The response
for each command is shown below the user input.
Connecting to /var/run/dpdk/rte/process_info.22103
--> /
{"/":["/","/eal:app_params","/eal:params","/eal:version"]}
--> /eal:version
{"/eal:version":"DPDK 20.02.0-rc0"}
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
usertools/test_new_telemetry.py | 28
1 file changed, 28 insertions(+)
create mode 100755 usertools/test_new_telemetry.py
diff --git a/usertools/test_new_telemetry.py b/usertools/test_new_telemetry.py
new file mode 100755
index 0..84243ffae
--- /dev/null
+++ b/usertools/test_new_telemetry.py
@@ -0,0 +1,28 @@
+#! /usr/bin/python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+import socket
+import os
+import sys
+import time
+import glob
+
+def handle_socket(path):
+print("Connecting to " + path)
+try:
+fd.connect(path)
+except OSError:
+return
+text = input('--> ')
+while (text != "quit"):
+fd.send(text.encode())
+print(fd.recv(4096).decode())
+text = input('--> ')
+fd.close()
+
+fd = socket.socket(socket.AF_UNIX, socket.SOCK_SEQPACKET)
+for f in glob.glob('/var/run/dpdk/*/process_info.*'):
+ handle_socket(f)
+for f in glob.glob('/run/user/%d/dpdk/*/process_info.*' % os.getuid()):
+ handle_socket(f)
--
2.17.1
[dpdk-dev] [RFC 0/6] replace telemetry with process_info
From: Bruce Richardson This patchset proposes a new library, called "process-info" for now, to replace the existing telemetry library in DPDK. (Name subject to change if someone can propose a better one). The existing telemetry library provides useful capabilities if used: - Creates a unix socket on the system to allow external programs connect and gather stats about the DPDK process. - Supports outputting the xstats for various network cards on the system. - Can be used to output any other information exported to the metrics library, e.g. by applications. - Uses JSON message format, which is widely supported by other languages and systems. - Is supported by a plugin to collectd. However, the library also has some issues and limitations that could be improved upon: - Has a dependency on libjansson for JSON processing, so is disabled by default. - Tied entirely to the metrics library for statistics. - No support for sending non-stats data, e.g. something as simple as DPDK version string. - All data gathering functions are in the library itself, which also means… - No support for libraries or drivers to present their own information via the library. We therefore propose to keep the good points of the existing library, but change the way things work to rectify the downsides. This leads to the following design choices in the library: - Keep the existing idea of using a unix socket for connection (just simplifying the connection handling). - We would like to use JSON format, where possible, but the jansson library dependency is problematic. However, creating JSON-encoded data is easier than trying to parse JSON in C code, so we can keep the JSON output format for processing by e.g. collectd and other tools, while simplifying the input to be plain text commands: - Commands in this RFC are designed to all start with "/" for consistency - Any parameters to the commands, e.g. the specific port to get stats for, are placed after a comma "," - Have the library only handle socket creation and input handling. All data gathering should be provided by functions external to the library registered by other components, e.g. have ethdev library provide the function to query NIC xstats, etc. - Have the library directly initialized by EAL by default, so that unless an app explicitly does not want the support, monitoring is available on all DPDK apps. The obvious question that remains to be answered here is: "why a new library rather than just fixing the old one?" The answer is that we have conflicts between the final two design choices above, which require that the library be built early in the build as other libraries will call into it to register callbacks, and the desire to keep backward compatibility e.g. for use with collectd plugin, which requires the existing library code be kept around and built - as it is now - at the end of the build process since it calls into other DPDK libraries. We therefore cannot have one library that meets both requirements, hence the replacement which allows us to maintain backward compatibility by just leaving the old lib in place until e.g. 20.11. This is also why the new library is called "process_info", since the name "telemetry" is already taken. Suggestions for a better name welcome. Bruce Richardson (4): process-info: introduce process-info library eal: integrate process-info library usertools: add process-info python script ethdev: add callback support for process-info Ciara Power (2): rawdev: add callback support for process-info examples/l3fwd-power: enable use of process-info config/common_base| 5 + examples/l3fwd-power/main.c | 83 ++- lib/Makefile | 3 +- lib/librte_eal/common/eal_common_options.c| 75 ++ lib/librte_eal/common/eal_internal_cfg.h | 1 + lib/librte_eal/common/eal_options.h | 5 + lib/librte_eal/freebsd/eal/Makefile | 1 + lib/librte_eal/freebsd/eal/eal.c | 14 ++ lib/librte_eal/linux/eal/Makefile | 1 + lib/librte_eal/linux/eal/eal.c| 15 ++ lib/librte_eal/meson.build| 2 +- lib/librte_ethdev/Makefile| 2 +- lib/librte_ethdev/rte_ethdev.c| 73 ++ lib/librte_process_info/Makefile | 26 ++ lib/librte_process_info/meson.build | 8 + lib/librte_process_info/process_info.c| 231 ++ lib/librte_process_info/rte_process_info.h| 25 ++ .../rte_process_info_version.map | 6 + lib/librte_rawdev/Makefile| 3 +- lib/librte_rawdev/meson.build | 1 + lib/librte_rawdev/rte_rawdev.c| 82 +++ lib/meson.build | 1 + mk/rte.app.mk
[dpdk-dev] [RFC 5/6] rawdev: add callback support for process-info
The rawdev library now registers commands with process_info, and
implements the corresponding callback functions. These allow a list of
rawdev devices and stats for a rawdev port to be queried.
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
lib/librte_rawdev/Makefile | 3 +-
lib/librte_rawdev/meson.build | 1 +
lib/librte_rawdev/rte_rawdev.c | 82 ++
3 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/lib/librte_rawdev/Makefile b/lib/librte_rawdev/Makefile
index 7dd1197dc..6e1d4ea05 100644
--- a/lib/librte_rawdev/Makefile
+++ b/lib/librte_rawdev/Makefile
@@ -9,7 +9,8 @@ LIB = librte_rawdev.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
-LDLIBS += -lrte_eal
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+LDLIBS += -lrte_eal -lrte_process_info
# library source files
SRCS-y += rte_rawdev.c
diff --git a/lib/librte_rawdev/meson.build b/lib/librte_rawdev/meson.build
index a20fbdc04..dcd37ad49 100644
--- a/lib/librte_rawdev/meson.build
+++ b/lib/librte_rawdev/meson.build
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+allow_experimental_apis = true
sources = files('rte_rawdev.c')
headers = files('rte_rawdev.h', 'rte_rawdev_pmd.h')
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index b6f1e1c77..477e12af6 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "rte_rawdev.h"
#include "rte_rawdev_pmd.h"
@@ -544,9 +545,90 @@ rte_rawdev_pmd_release(struct rte_rawdev *rawdev)
return 0;
}
+static int
+handle_dev_list(const char *cmd __rte_unused,
+ const char *params __rte_unused,
+ char *buffer, int buf_len)
+{
+ int used = 0;
+ int i;
+
+ used = strlcpy(buffer, "[", buf_len);
+ for (i = 0; i < rawdev_globals.nb_devs; i++)
+ if (rte_rawdevices[i].attached == RTE_RAWDEV_ATTACHED)
+ used += snprintf(buffer + used, buf_len - used, "%d,",
+ rte_rawdevices[i].dev_id);
+
+ buffer[used - 1] = ']';
+ return used;
+}
+
+static int
+handle_dev_stats(const char *cmd __rte_unused,
+ const char *params,
+ char *buffer, int buf_len)
+{
+ uint64_t *rawdev_xstats;
+ struct rte_rawdev_xstats_name *xstat_names;
+ int dev_id, num_xstats, i, ret;
+ int used = 0;
+ unsigned int *ids;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ dev_id = atoi(params);
+ if (!rte_rawdev_pmd_is_valid_dev(dev_id))
+ return -1;
+
+ used = strlcpy(buffer, "{", buf_len);
+
+ num_xstats = xstats_get_count(dev_id);
+ if (num_xstats < 0)
+ return -1;
+
+ /* use one malloc for names, stats and ids */
+ rawdev_xstats = malloc((sizeof(uint64_t) +
+ sizeof(struct rte_rawdev_xstats_name) +
+ sizeof(unsigned int)) * num_xstats);
+ if (rawdev_xstats == NULL)
+ return -1;
+ xstat_names = (void *)&rawdev_xstats[num_xstats];
+ ids = (void *)&xstat_names[num_xstats];
+
+ ret = rte_rawdev_xstats_names_get(dev_id, xstat_names, num_xstats);
+ if (ret < 0 || ret > num_xstats) {
+ free(rawdev_xstats);
+ return -1;
+ }
+
+ for (i = 0; i < num_xstats; i++)
+ ids[i] = i;
+
+ ret = rte_rawdev_xstats_get(dev_id, ids, rawdev_xstats, num_xstats);
+ if (ret < 0 || ret > num_xstats) {
+ free(rawdev_xstats);
+ return -1;
+ }
+
+ for (i = 0; i < num_xstats; i++) {
+ ret = snprintf(buffer + used, buf_len - used,
"\"%s\":%"PRIu64",",
+ xstat_names[i].name, rawdev_xstats[i]);
+ if (ret + used >= buf_len)
+ break;
+ used += ret;
+ }
+
+ buffer[used - 1] = '}';
+ free(rawdev_xstats);
+ return used;
+}
+
RTE_INIT(librawdev_init_log)
{
librawdev_logtype = rte_log_register("lib.rawdev");
if (librawdev_logtype >= 0)
rte_log_set_level(librawdev_logtype, RTE_LOG_INFO);
+ rte_process_info_register("/rawdev:list", handle_dev_list);
+ rte_process_info_register("/rawdev:stats", handle_dev_stats);
}
--
2.17.1
[dpdk-dev] [RFC 6/6] examples/l3fwd-power: enable use of process-info
The l3fwd-power example app now registers a stats command with
process_info, and provides a callback function to handle formatting the
power stats.
Using the process-info library in this app replaces the previous method
of making l3fwd-power stats available in the metrics library, for use
with telemetry.
Signed-off-by: Bruce Richardson
Signed-off-by: Ciara Power
---
examples/l3fwd-power/main.c | 83 +++--
1 file changed, 25 insertions(+), 58 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index d049d8a5d..939b3dd88 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -45,7 +45,7 @@
#include
#include
#include
-#include
+#include
#include "perf_core.h"
#include "main.h"
@@ -131,7 +131,7 @@
#define EMPTY_POLL_MED_THRESHOLD 35UL
#define EMPTY_POLL_HGH_THRESHOLD 58UL
-
+#define NUM_TELSTATS RTE_DIM(telstats_strings)
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
@@ -154,11 +154,6 @@ volatile bool quit_signal;
static struct ep_params *ep_params;
static struct ep_policy policy;
static long ep_med_edpi, ep_hgh_edpi;
-/* timer to update telemetry every 500ms */
-static struct rte_timer telemetry_timer;
-
-/* stats index returned by metrics lib */
-int telstats_index;
struct telstats_name {
char name[RTE_ETH_XSTATS_NAME_SIZE];
@@ -187,9 +182,6 @@ enum busy_rate {
#define MIN_CYCLES 150ULL
#define MAX_CYCLES 2200ULL
-/* (500ms) */
-#define TELEMETRY_INTERVALS_PER_SEC 2
-
static int parse_ptype; /**< Parse packet type using rx callback, and */
/**< disabled by default */
@@ -2087,17 +2079,21 @@ init_power_library(void)
}
return ret;
}
-static void
-update_telemetry(__attribute__((unused)) struct rte_timer *tim,
- __attribute__((unused)) void *arg)
+
+static int
+handle_app_stats(const char *cmd __rte_unused,
+ const char *params __rte_unused,
+ char *buffer, int buf_len)
{
unsigned int lcore_id = rte_lcore_id();
struct lcore_conf *qconf;
uint64_t app_eps = 0, app_fps = 0, app_br = 0;
- uint64_t values[3] = {0};
- int ret;
+ uint64_t values[NUM_TELSTATS];
+ int ret, used = 0;
+ uint32_t i;
uint64_t count = 0;
+ used = strlcpy(buffer, "{", buf_len);
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
qconf = &lcore_conf[lcore_id];
if (qconf->n_rx_queue == 0)
@@ -2114,32 +2110,21 @@ update_telemetry(__attribute__((unused)) struct
rte_timer *tim,
values[0] = app_eps/count;
values[1] = app_fps/count;
values[2] = app_br/count;
- } else {
- values[0] = 0;
- values[1] = 0;
- values[2] = 0;
+ } else
+ memset(values, 0, sizeof(uint64_t) * NUM_TELSTATS);
+
+ for (i = 0; i < NUM_TELSTATS; i++) {
+ ret = snprintf(buffer + used, buf_len - used,
"\"%s\":%"PRIu64",",
+ telstats_strings[i].name, values[i]);
+ if (ret + used >= buf_len)
+ break;
+ used += ret;
}
- ret = rte_metrics_update_values(RTE_METRICS_GLOBAL, telstats_index,
- values, RTE_DIM(values));
- if (ret < 0)
- RTE_LOG(WARNING, POWER, "failed to update metrcis\n");
+ buffer[used - 1] = '}';
+ return used;
}
-static void
-telemetry_setup_timer(void)
-{
- int lcore_id = rte_lcore_id();
- uint64_t hz = rte_get_timer_hz();
- uint64_t ticks;
- ticks = hz / TELEMETRY_INTERVALS_PER_SEC;
- rte_timer_reset_sync(&telemetry_timer,
- ticks,
- PERIODICAL,
- lcore_id,
- update_telemetry,
- NULL);
-}
static void
empty_poll_setup_timer(void)
{
@@ -2176,8 +2161,6 @@ launch_timer(unsigned int lcore_id)
if (app_mode == APP_MODE_EMPTY_POLL)
empty_poll_setup_timer();
- else
- telemetry_setup_timer();
cycles_10ms = rte_get_timer_hz() / 100;
@@ -2196,7 +2179,6 @@ launch_timer(unsigned int lcore_id)
return 0;
}
-
int
main(int argc, char **argv)
{
@@ -2212,8 +2194,6 @@ main(int argc, char **argv)
uint32_t dev_rxq_num, dev_txq_num;
uint8_t nb_rx_queue, queue, socketid;
uint16_t portid;
- uint8_t num_telstats = RTE_DIM(telstats_strings);
- const char *ptr_strings[num_telstats];
/* catch SIGINT and restore cpufreq governor to ondemand */
signal(SIGINT, signal_exit_now);
@@ -2507,29 +2487,16 @@ main(int argc, char **argv)
rte_eal_mp_remote_launch(main_empty_poll_loop, NULL,
SKIP_MASTER);
} else
Re: [dpdk-dev] [PATCH 0/3] updates for bnxt PMD
On Sun, Dec 1, 2019 at 8:06 PM Kalesh A P < kalesh-anakkur.pura...@broadcom.com> wrote: > From: Kalesh AP > > This series contains code cleanup patches for bnxt PMD. > > Please apply. > Patches applied to dpdk-next-net-brcm. Thanks > > Kalesh AP (3): > net/bnxt: rework code to select chip type > net/bnxt: remove an unnecessary log > net/bnxt: use macro for getting default vnic > > drivers/net/bnxt/bnxt_ethdev.c | 91 > +++--- > drivers/net/bnxt/bnxt_hwrm.c | 1 - > 2 files changed, 51 insertions(+), 41 deletions(-) > > -- > 2.10.1 > >
Re: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker image
On 2019/12/05 23:13, Ruifeng Wang (Arm Technology China) wrote:
-Original Message-
From: dev On Behalf Of Abdul Halim
Sent: Tuesday, December 3, 2019 19:42
To: dev@dpdk.org
Cc: ray.kinse...@intel.com; yasufu...@gmail.com; Abdul Halim
Subject: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker
image
Adding a Dockerfile with Ubuntu bionic base image to build dpdk as shared
library. This docker image could be used as base image to build and run dpdk
applications in containers.
Signed-off-by: Abdul Halim
[...]
diff --git a/extras/README.md b/extras/README.md new file mode 100644
index 000..f38d7f1
--- /dev/null
+++ b/extras/README.md
@@ -0,0 +1,52 @@
+# Build DPDK Docker image
+
+To build a docker image run the following command from dpdk root
directory.
+
+```
+DOCKER_TAG="dpdk"
+docker build -t ${DOCKER_TAG} -f extras/Dockerfile.bionic .
+```
+
+# Example of how to use this dpdk library image
+
+The following steps shows how to use the dpdk shared library container
+to build and run a dpdk application without having to build dpdk
+library for each application.
+
+## Create a dpdk sample app docker file with 'dpdk' as the base image
+
+Create a docker file to build the dpdk helloworld application. Since,
+we are creating a docker file for dpdk helloworld app we need to add
+the dpdk source files, thus create the following docker file in dpdk root
directory.
+
+```
+cat << EOF > Dockerfile.dpdkSampleApp
+FROM dpdk
+
+ADD . /opt/dpdk
+
+WORKDIR /opt/dpdk/examples/helloworld
+RUN make && cp build/helloworld-shared /usr/local/bin/helloworld EOF
+```
+
+## Build sample app docker image
+
+```
+DOCKERAPP_TAG="dpdk-helloworld"
+docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
+```
Hi Abdul,
I tried the steps on AArch64 platform, and hit error as below:
$ sudo docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
Sending build context to Docker daemon 2.55GB
Step 1/4 : FROM dpdk
---> 955448007987
Step 2/4 : ADD . /opt/dpdk
---> d8b58019a7e2
Step 3/4 : WORKDIR /opt/dpdk/examples/helloworld
---> Running in 14fc89f7d3cd
Removing intermediate container 14fc89f7d3cd
---> 065a682c58fd
Step 4/4 : RUN make && cp build/helloworld-shared /usr/local/bin/helloworld
---> Running in 11e755a7180b
Makefile:44: *** "Please define RTE_SDK environment variable". Stop.
The command '/bin/sh -c make && cp build/helloworld-shared
/usr/local/bin/helloworld' returned a non-zero code: 2
Missing define of RTE_SDK and RTE_TARGET?
Hi Ruifeng,
I think you run you run the command in dpdk/extras. However, this
'Dockerfile.dpdkSampleApp' is expected to be run in dpdk's root dir so
that it is mounted as '/opt/dpdk' in the second step above. I have
tested this Dockerfile on Ubuntu 18.04 and compiled without any error.
RTE_SDK is set correctly, but dpdk's directory is not mounted in the
container.
Abdul,
>> +docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
I think this line should be corrected as following, and make it clear it
should be run in dpdk's root.
docker build -t ${DOCKERAPP_TAG} -f extras/Dockerfile.dpdkSampleApp .
Even if the container image is built successfully, there is another
problem in running app because it isn't run in privileged mode.
root@0d2a309dfd2c:/opt/dpdk/examples/helloworld# helloworld
EAL: Detected 16 lcore(s)
EAL: Detected 1 NUMA nodes
...
EAL: Failed to get current mempolicy: Operation not permitted. Assuming
MPOL_DEFAULT.
set_mempolicy: Operation not permitted
set_mempolicy: Operation not permitted
EAL: error allocating rte services array
EAL: FATAL: rte_service_init() failed
EAL: rte_service_init() failed
PANIC in main():
Cannot init EAL
5: [helloworld(+0x84a) [0x484a]]
4: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
[0x77721b97]]
3: [helloworld(+0x818) [0x4818]]
2: [/usr/local/lib/x86_64-linux-gnu/librte_eal.so.20.1(__rte_panic+0xbd)
[0x77afb410]]
1:
[/usr/local/lib/x86_64-linux-gnu/librte_eal.so.20.1(rte_dump_stack+0x2e)
[0x77b1598e]]
Aborted (core dumped)
I think '--privileged' option should be added to avoid the error.
$ docker run --rm --privileged -it -v /dev/hugepages:/dev/hugepages
dpdk-helloworld
I have one more suggestion. You might have added $USER to docker group
and run docker without sudo like as following.
$ sudo groupadd docker
$ sudo usermod -aG docker $USER
I wounder it is better to use sudo in your examples, or add the
instruction for users not familiar with docker.
Regards,
Yasufumi
+
+This sample app now can be run like any other applicaiton in a docker
container.
+
+```
+$ docker run --rm -it -v /dev/hugepages:/dev/hugepages dpdk-helloworld
+```
+
+## Running the sample app
+Once inside the container run helloword binary
+
+```
+$ root@11233ed2e69c # helloworld
+```
+
--
1.8.3.1
--
Intel Research and Development Ireland Limited Registered in Ireland
Registered
Re: [dpdk-dev] [PATCH v7 1/1] fbarray: fix duplicated fbarray file in secondary
Hi Anatoly,
On 2019/12/02 19:43, Burakov, Anatoly wrote:
On 29-Nov-19 5:44 AM, Yasufumi Ogawa wrote:
Hi Anatoly,
On 2019/11/27 19:26, Burakov, Anatoly wrote:
On 26-Nov-19 7:40 PM, Yasufumi Ogawa wrote:
Hi David,
Sorry for slow reply.
On 2019/11/14 21:27, David Marchand wrote:
On Thu, Nov 14, 2019 at 12:42 PM Yasufumi Ogawa
wrote:
On 2019/11/14 2:01, Burakov, Anatoly wrote:
On 13-Nov-19 9:43 PM, yasufu...@gmail.com wrote:
From: Yasufumi Ogawa
In secondary_msl_create_walk(), it creates a file for fbarrays
with its
PID for reserving unique name among secondary processes.
However, it
does not work if several secondaries run as app containers
because each
of containerized secondary has PID 1, and failed to reserve
unique name
other than first one. To reserve unique name in each of
containers, use
hostname in addition to PID.
Cc: sta...@dpdk.org
Signed-off-by: Yasufumi Ogawa
---
lib/librte_eal/linux/eal/eal_memalloc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
b/lib/librte_eal/linux/eal/eal_memalloc.c
index af6d0d023..11de6d4d6 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -1365,6 +1365,12 @@ secondary_msl_create_walk(const struct
rte_memseg_list *msl,
struct rte_memseg_list *primary_msl, *local_msl;
char name[PATH_MAX];
int msl_idx, ret;
+ char hostname[HOST_NAME_MAX+1] = { 0 };
+ /* filename of secondary's fbarray is defined such as
+ * "fbarray_memseg-1048576k-0-0_PID_HOSTNAME" and length of
PID
+ * can be 7 digits maximumly.
+ */
+ int fbarray_sec_name_len = 32 + 7 + 1 + HOST_NAME_MAX + 1;
What does 32 stand for? Maybe #define both 32 and 7 values?
Hi Anatoly,
Thank you for your comments! If my understanding is correct, the
prefix
"fbarray_memseg-1048576k-0-0_" is 28 digits and it could be larger if
using the size of hugepage or the number of NUMA nodes are larger
possibly. However, I think 32 digits is still enough.
> Maybe #define both 32 and 7 values?
Yes. I think it should be better to use #define if this values are
referred several times.
We can truncate to RTE_FBARRAY_NAME_LEN in all cases.
And iiuc, rte_fbarray_init will refuse any longer name anyway.
Could I confirm the issue? I've understood that it is failed to
validate the name of fbarray in fully_validate() at
"lib/librte_eal/common/eal_common_fbarray.c:697".
static int
fully_validate(const char *name, unsigned int elt_sz, unsigned int len)
{
if (name == NULL || elt_sz == 0 || len == 0 || len >
INT_MAX) {
rte_errno = EINVAL;
return -1;
}
if (strnlen(name, RTE_FBARRAY_NAME_LEN) ==
RTE_FBARRAY_NAME_LEN) {
rte_errno = ENAMETOOLONG;
return -1;
}
return 0;
}
I should overwrite the definition of RTE_FBARRAY_NAME_LEN as
previous patch in this case, and it causes an ABI breakage, right?
If so, I would like to make the change and give up to update stable
release.
Thanks,
Yasufumi
It seems we're getting into bikeshedding...
We can do this without ABI breakage. You could have just used
RTE_FBARRAY_NAME_LEN as max fbarray name length for
fbarray_sec_name_len (i.e. that would include hostname + pid +
whatever else there is). The name, as David has pointed out, would be
truncated to RTE_FBARRAY_NAME_LEN anyway (or, more precisely, it will
be refused if it's longer than that), so this is the most you can
have - so you can just use that as the maximum.
I sent v8 patch to change the size of RTE_FBARRAY_NAME_LEN itself to
be allowed the size of secondary's fbarray over 64 bytes. I appreciate
if you agree that.
Why not just limit the name to RTE_FBARRAY_NAME_LEN instead of changing
the definition of RTE_FBARRAY_NAME_LEN?
Could I confirm my understanding? I understand that RTE_FBARRAY_NAME_LEN
is 64 currently and it is not enough for secondary in a container if
hostname is added to the name of secondary's fbarray.
Regards,
Yasufumi
One the other hand, technically, fbarray API is experimental. The only
structure that uses rte_fbarray is rte_memseg_list, but API's using
either rte_fbarray or rte_memseg_list are either internal (memory/VFIO
subsystem), or are marked as experimental (walk functions).
So i *think* we're actually OK with changing the length of
RTE_FBARRAY_NAME_LEN as far as ABI policy goes: nothing in the stable
ABI gets affected. David, thoughts?
(i think it's probably time to make experimental memory/fbarray stuff
stable, but that's a different conversation...)
Thanks,
Yasufumi
Re: [dpdk-dev] [PATCH 4/5] examples/ipsecgw: add SPDX license tag
> This trivial file had no license info.
>
> Signed-off-by: Stephen Hemminger
> ---
> .../ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh | 1 +
> .../ipsec-secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git
> a/examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> b/examples/ipsec-
> secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> index 875a7457d3e8..f21b01d63546 100644
> --- a/examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> +++ b/examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> @@ -1,4 +1,5 @@
> #! /bin/bash
> +# SPDX-License-Identifier: BSD-3-Clause
>
> . ${DIR}/trs_aesgcm_defs.sh
>
> diff --git
> a/examples/ipsec-secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> b/examples/ipsec-
> secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> index 6968484323c2..97b9431f42a0 100644
> --- a/examples/ipsec-secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> +++ b/examples/ipsec-secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> @@ -1,4 +1,5 @@
> #! /bin/bash
> +# SPDX-License-Identifier: BSD-3-Clause
>
> . ${DIR}/tun_aesgcm_defs.sh
>
> --
Acked-by: Konstantin Ananyev
> 2.20.1
[dpdk-dev] eventdev DSW question
I see that the provision in 18.11 eventdev DSW for maximum number of queues is #define DSW_MAX_QUEUES (16) 1. If the number of queues needed is to be increased to 7 bits (i.e. 128) is there any issue (correctness, scale, performance) other than increased data structure size? 2. I see that it is only used in the following structs: - struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES]; sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to 4MB - struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES], queue_dequeued[DSW_MAX_QUEUES]; This increase is negligible (a few KB at most across all dsw_ports) 3. So is it enough if I changed the above define? (In other words I hope there are no other hidden/implicit dependencies on the current value 16 elsewhere in the code). Also I suppose the only way is to directly change this in the code, rite? Thanks -Venky
Re: [dpdk-dev] [PATCH] net/fm10k: fix descriptor vlan field filling in Tx
Hi,
> -Original Message-
> From: Lu Qiuwen
> Sent: Thursday, December 5, 2019 9:30 PM
> To: Zhang, Qi Z ; Wang, Xiao W
>
> Cc: dev@dpdk.org; Shaw, Jeffrey B ;
> sta...@dpdk.org
> Subject: [PATCH] net/fm10k: fix descriptor vlan field filling in Tx
>
> The VLAN field in the descriptor is not filled when ol_flags has
> no VLAN flag. When the caller sends some packets with VLAN tags,
> but other packets do not have VLAN tags, the behavior of the program
> cannot be determined.
>
> Fixes: 4b61d3bfa941 ("fm10k: add receive and tranmit")
> Cc: jeffrey.b.s...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Lu Qiuwen
> ---
> drivers/net/fm10k/fm10k_rxtx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index 5c3112183..4accaa2cd 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -611,6 +611,8 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q,
> struct rte_mbuf *mb)
> /* set vlan if requested */
> if (mb->ol_flags & PKT_TX_VLAN_PKT)
> q->hw_ring[q->next_free].vlan = mb->vlan_tci;
> + else
> + q->hw_ring[q->next_free].vlan = 0;
>
> q->sw_ring[q->next_free] = mb;
> q->hw_ring[q->next_free].buffer_addr =
> --
> 2.20.1.windows.1
Acked-by: Xiao Wang
Re: [dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com
On Thu, Dec 05, 2019 at 01:26:36PM +, Matan Azrad wrote: > Hi all > > As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, a new vdpa > drivers is going to be added for Mellanox devices – mlx5_vdpa > > The only vdpa driver now is the IFC driver that is located in net directory. > > The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and not the > eth_dev ops. > > All the others drivers in net provide the eth-dev ops. > > I suggest to create a new class for vdpa drivers, to move IFC to this class > and > to add the mlx5_vdpa to this class too. > > Later, all the new drivers that implements the vdpa ops will be added to the > vdpa class. +1. Sounds like a good idea to me. Thanks, Tiwei > > Will be nice to see your comments. > > Matan >
Re: [dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com
> -Original Message- > From: Bie, Tiwei > Sent: Friday, December 6, 2019 12:28 PM > To: Matan Azrad > Cc: Wang, Xiao W ; Thomas Monjalon > ; maxime.coque...@redhat.com; Wang, Zhihong > ; Yigit, Ferruh ; Shahaf > Shuler > ; Ori Kam ; dev@dpdk.org; Slava > Ovsiienko ; Asaf Penso ; Olga > Shern ; Liang, Cunming > Subject: Re: discussion: creating a new class for vdpa > driversxiao.w.w...@intel.com > > On Thu, Dec 05, 2019 at 01:26:36PM +, Matan Azrad wrote: > > Hi all > > > > As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, a > > new vdpa drivers is going to be added for Mellanox devices – mlx5_vdpa > > > > The only vdpa driver now is the IFC driver that is located in net directory. > > > > The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and > > not the eth_dev ops. > > > > All the others drivers in net provide the eth-dev ops. > > > > I suggest to create a new class for vdpa drivers, to move IFC to this > > class and to add the mlx5_vdpa to this class too. > > > > Later, all the new drivers that implements the vdpa ops will be added > > to the vdpa class. > > +1. Sounds like a good idea to me. +1 > > Thanks, > Tiwei > > > > > Will be nice to see your comments. > > > > Matan > >
Re: [dpdk-dev] eventdev DSW question
+ DSW maintainer On Fri, Dec 6, 2019 at 5:57 AM Venky Venkatesh wrote: > > I see that the provision in 18.11 eventdev DSW for maximum number of queues > is > > #define DSW_MAX_QUEUES (16) > > > >1. If the number of queues needed is to be increased to 7 bits (i.e. >128) is there any issue (correctness, scale, performance) other than >increased data structure size? >2. I see that it is only used in the following structs: > - struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES]; > sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase > contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to 4MB > - struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES], > queue_dequeued[DSW_MAX_QUEUES]; > This increase is negligible (a few KB at most across all dsw_ports) >3. So is it enough if I changed the above define? (In other words I hope >there are no other hidden/implicit dependencies on the current value 16 >elsewhere in the code). Also I suppose the only way is to directly change >this in the code, rite? > > Thanks > > -Venky
[dpdk-dev] [PATCH] net/i40e: fix flow control broken
Repeat switching flow control on or off during receiving traffic,
testpmd reports "failed to switch Tx queue occurs" after quit.
The patch fixes the issue.
Fixes: f53577f06925 ("i40e: support flow control")
Cc: sta...@dpdk.org
Signed-off-by: Guinan Sun
---
drivers/net/i40e/i40e_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5999c964b..5507f6c39 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -53,7 +53,7 @@
/* Wait count and interval */
#define I40E_CHK_Q_ENA_COUNT 1000
-#define I40E_CHK_Q_ENA_INTERVAL_US 1000
+#define I40E_CHK_Q_ENA_INTERVAL_US 5
/* Maximun number of VSI */
#define I40E_MAX_NUM_VSIS (384UL)
--
2.17.1
