[dpdk-dev] [PATCH v5 0/6] vhost: optimize enqueue

[Yuanhan Liu]

On Mon, Sep 12, 2016 at 03:52:12PM +0200, Maxime Coquelin wrote:
> Just tried to apply your series without success.
> Apparently, it is not based directly on master branch,
> as it lacks some SHA-1 information.
> 
> Could you rebase it against master please?

It's rebased against the dpdk-next-virtio tree [0], where all the
virtio/vhost patches are applied first.

[0]: http://dpdk.org/browse/next/dpdk-next-virtio/

--yliu

[dpdk-dev] [PATCH v2 2/2] app/test: add test cases for NULL for Intel QAT driver

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

Added NULL algorithm to test file for Intel(R) QuickAssist
Technology Driver

Signed-off-by: Deepak Kumar Jain 
---
 app/test/test_cryptodev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 8553759..67ca912 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -4136,6 +4136,16 @@ static struct unit_test_suite cryptodev_qat_testsuite  = 
{
TEST_CASE_ST(ut_setup, ut_teardown,
test_MD5_HMAC_verify_case_2),

+   /** NULL tests */
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_auth_only_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_cipher_only_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_cipher_auth_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_auth_cipher_operation),
+
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
-- 
2.5.5

[dpdk-dev] [PATCH v2 1/2] crypto/qat: add NULL capability to Intel QAT driver

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

enabled NULL crypto for Intel(R) QuickAssist Technology

Signed-off-by: Deepak Kumar Jain 
---
 doc/guides/cryptodevs/qat.rst| 3 ++-
 doc/guides/rel_notes/release_16_11.rst   | 1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 2 ++
 drivers/crypto/qat/qat_crypto.c  | 4 
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 78a734f..bb62f22 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -49,6 +49,7 @@ Cipher algorithms:
 * ``RTE_CRYPTO_SYM_CIPHER_AES256_CTR``
 * ``RTE_CRYPTO_SYM_CIPHER_SNOW3G_UEA2``
 * ``RTE_CRYPTO_CIPHER_AES_GCM``
+* ``RTE_CRYPTO_CIPHER_NULL``

 Hash algorithms:

@@ -60,7 +61,7 @@ Hash algorithms:
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
 * ``RTE_CRYPTO_AUTH_MD5_HMAC``
-
+* ``RTE_CRYPTO_AUTH_NULL``

 Limitations
 ---
diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 9b2f102..9b2c775 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -42,6 +42,7 @@ New Features
   * Added support for MD5_HMAC algorithm.
   * Added support for SHA224-HMAC algorithm.
   * Added support for SHA384-HMAC algorithm.
+  * Added support for NULL algorithm.


 Resolved Issues
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index af8c176..d9437bc 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -720,6 +720,8 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
}
state2_size = ICP_QAT_HW_MD5_STATE2_SZ;
break;
+   case ICP_QAT_HW_AUTH_ALGO_NULL:
+   break;
default:
PMD_DRV_LOG(ERR, "Invalid HASH alg %u", cdesc->qat_hash_alg);
return -EFAULT;
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 60e2ba2..be2b9be 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -469,6 +469,8 @@ qat_crypto_sym_configure_session_cipher(struct 
rte_cryptodev *dev,
session->qat_mode = ICP_QAT_HW_CIPHER_ECB_MODE;
break;
case RTE_CRYPTO_CIPHER_NULL:
+   session->qat_mode = ICP_QAT_HW_CIPHER_ECB_MODE;
+   break;
case RTE_CRYPTO_CIPHER_3DES_ECB:
case RTE_CRYPTO_CIPHER_3DES_CBC:
case RTE_CRYPTO_CIPHER_AES_ECB:
@@ -600,6 +602,8 @@ qat_crypto_sym_configure_session_auth(struct rte_cryptodev 
*dev,
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_MD5;
break;
case RTE_CRYPTO_AUTH_NULL:
+   session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_NULL;
+   break;
case RTE_CRYPTO_AUTH_SHA1:
case RTE_CRYPTO_AUTH_SHA256:
case RTE_CRYPTO_AUTH_SHA512:
-- 
2.5.5

[dpdk-dev] [PATCH v2 0/2] add NULL crypto support in Intel QAT driver

[Deepak Kumar Jain]

This patchset adds support of NULL crypto in Intel(R) QuickAssist Technology 
driver.

This patchset depends on following patchset:
"crypto/qat: add aes-sha384-hmac capability to Intel QAT driver"
(http://dpdk.org/dev/patchwork/patch/15778/)


Deepak Kumar JAIN (2):
  crypto/qat: add NULL capability to Intel QAT driver
  app/test: add test cases for NULL for Intel QAT driver

Changes in V1:
* Added new feature information in release_16_11.rst file.

 app/test/test_cryptodev.c| 10 ++
 doc/guides/cryptodevs/qat.rst|  3 ++-
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  2 ++
 drivers/crypto/qat/qat_crypto.c  |  4 
 5 files changed, 19 insertions(+), 1 deletion(-)

-- 
2.5.5

[dpdk-dev] [PATCH v2 2/2] app/test: add test cases for aes-sha384-hmac for Intel QAT driver

[Deepak Kumar Jain]

From: "Jain, Deepak K" 

Added aes-sha384-hmac algorithm to test file for Intel(R) QuickAssist
Technology Driver

Signed-off-by: Deepak Kumar Jain 
---
 app/test/test_cryptodev_aes.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_aes.c b/app/test/test_cryptodev_aes.c
index 6ad2674..e19c45b 100644
--- a/app/test/test_cryptodev_aes.c
+++ b/app/test/test_cryptodev_aes.c
@@ -226,14 +226,16 @@ static const struct aes_test_case aes_test_cases[] = {
.test_descr = "AES-128-CBC HMAC-SHA384 Encryption Digest",
.test_data = _test_data_9,
.op_mask = AES_TEST_OP_ENC_AUTH_GEN,
-   .pmd_mask = AES_TEST_TARGET_PMD_MB
+   .pmd_mask = AES_TEST_TARGET_PMD_MB |
+   AES_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-128-CBC HMAC-SHA384 Decryption Digest "
"Verify",
.test_data = _test_data_9,
.op_mask = AES_TEST_OP_AUTH_VERIFY_DEC,
-   .pmd_mask = AES_TEST_TARGET_PMD_MB
+   .pmd_mask = AES_TEST_TARGET_PMD_MB |
+   AES_TEST_TARGET_PMD_QAT
},
 };

-- 
2.5.5

[dpdk-dev] [PATCH v2 1/2] crypto/qat: add aes-sha384-hmac capability to Intel QAT driver

[Deepak Kumar Jain]

From: "Jain, Deepak K" 

enabled support of aes-sha384-hmac in Intel(R) QuickAssist driver

Signed-off-by: Deepak Kumar Jain 
---
 doc/guides/cryptodevs/qat.rst|  1 +
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 
 drivers/crypto/qat/qat_crypto.c  | 31 +++---
 4 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 7f630be..78a734f 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -55,6 +55,7 @@ Hash algorithms:
 * ``RTE_CRYPTO_AUTH_SHA1_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA224_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA256_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA384_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 040e250..9b2f102 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -41,6 +41,7 @@ New Features

   * Added support for MD5_HMAC algorithm.
   * Added support for SHA224-HMAC algorithm.
+  * Added support for SHA384-HMAC algorithm.


 Resolved Issues
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index 77e6548..af8c176 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -77,6 +77,9 @@ static int qat_hash_get_state1_size(enum icp_qat_hw_auth_algo 
qat_hash_alg)
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA256_STATE1_SZ,
QAT_HW_DEFAULT_ALIGNMENT);
+   case ICP_QAT_HW_AUTH_ALGO_SHA384:
+   return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA384_STATE1_SZ,
+   QAT_HW_DEFAULT_ALIGNMENT);
case ICP_QAT_HW_AUTH_ALGO_SHA512:
return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA512_STATE1_SZ,
QAT_HW_DEFAULT_ALIGNMENT);
@@ -114,6 +117,8 @@ static int qat_hash_get_digest_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
return ICP_QAT_HW_SHA224_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return ICP_QAT_HW_SHA256_STATE1_SZ;
+   case ICP_QAT_HW_AUTH_ALGO_SHA384:
+   return ICP_QAT_HW_SHA384_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
return ICP_QAT_HW_SHA512_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_MD5:
@@ -138,6 +143,8 @@ static int qat_hash_get_block_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
return SHA256_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return SHA256_CBLOCK;
+   case ICP_QAT_HW_AUTH_ALGO_SHA384:
+   return SHA512_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
return SHA512_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_GALOIS_128:
@@ -187,6 +194,17 @@ static int partial_hash_sha256(uint8_t *data_in, uint8_t 
*data_out)
return 0;
 }

+static int partial_hash_sha384(uint8_t *data_in, uint8_t *data_out)
+{
+   SHA512_CTX ctx;
+
+   if (!SHA384_Init())
+   return -EFAULT;
+   SHA512_Transform(, data_in);
+   rte_memcpy(data_out, , SHA512_DIGEST_LENGTH);
+   return 0;
+}
+
 static int partial_hash_sha512(uint8_t *data_in, uint8_t *data_out)
 {
SHA512_CTX ctx;
@@ -252,6 +270,13 @@ static int partial_hash_compute(enum icp_qat_hw_auth_algo 
hash_alg,
*hash_state_out_be32 =
rte_bswap32(*(((uint32_t *)digest)+i));
break;
+   case ICP_QAT_HW_AUTH_ALGO_SHA384:
+   if (partial_hash_sha384(data_in, digest))
+   return -EFAULT;
+   for (i = 0; i < digest_size >> 3; i++, hash_state_out_be64++)
+   *hash_state_out_be64 =
+   rte_bswap64(*(((uint64_t *)digest)+i));
+   break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
if (partial_hash_sha512(data_in, digest))
return -EFAULT;
@@ -616,6 +641,14 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
}
state2_size = ICP_QAT_HW_SHA256_STATE2_SZ;
break;
+   case ICP_QAT_HW_AUTH_ALGO_SHA384:
+   if (qat_alg_do_precomputes(ICP_QAT_HW_AUTH_ALGO_SHA384,
+   authkey, authkeylen, cdesc->cd_cur_ptr, _size)) {
+   PMD_DRV_LOG(ERR, "(SHA)precompute failed");
+   return -EFAULT;
+   }
+   state2_size = ICP_QAT_HW_SHA384_STATE2_SZ;
+   break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
if 

[dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel QAT driver

[Deepak Kumar Jain]

This patchset adds support of aes-sha384-hmac in Intel(R) QuickAssist 
Technology driver.

This patchset depends on following patchset:
"crypto/qat: add aes-sha224-hmac capability to Intel QAT driver"
(http://dpdk.org/dev/patchwork/patch/15776/)


Jain, Deepak K (2):
  crypto/qat: add aes-sha384-hmac capability to Intel QAT driver
  app/test: add test cases for aes-sha384-hmac for Intel QAT driver

Changes from V1:
* Added new feature information in release_16_11.rst file.
* Added information about sha384-hmac in capabilities.

 app/test/test_cryptodev_aes.c|  6 +++--
 doc/guides/cryptodevs/qat.rst|  1 +
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 
 drivers/crypto/qat/qat_crypto.c  | 31 +++---
 5 files changed, 66 insertions(+), 6 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v2 2/2] app/test: add test cases for aes-sha224-hmac for Intel QAT driver

[Deepak Kumar Jain]

From: "Jain, Deepak K" 

Added aes-sha224-hmac algorithm to test file for Intel(R) QuickAssist
Technology Driver

Signed-off-by: Deepak Kumar Jain 
---
 app/test/test_cryptodev_aes.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_aes.c b/app/test/test_cryptodev_aes.c
index bf832b6..6ad2674 100644
--- a/app/test/test_cryptodev_aes.c
+++ b/app/test/test_cryptodev_aes.c
@@ -211,14 +211,16 @@ static const struct aes_test_case aes_test_cases[] = {
.test_descr = "AES-128-CBC HMAC-SHA224 Encryption Digest",
.test_data = _test_data_8,
.op_mask = AES_TEST_OP_ENC_AUTH_GEN,
-   .pmd_mask = AES_TEST_TARGET_PMD_MB
+   .pmd_mask = AES_TEST_TARGET_PMD_MB |
+   AES_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-128-CBC HMAC-SHA224 Decryption Digest "
"Verify",
.test_data = _test_data_8,
.op_mask = AES_TEST_OP_AUTH_VERIFY_DEC,
-   .pmd_mask = AES_TEST_TARGET_PMD_MB
+   .pmd_mask = AES_TEST_TARGET_PMD_MB |
+   AES_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-128-CBC HMAC-SHA384 Encryption Digest",
-- 
2.5.5

[dpdk-dev] [PATCH v2 1/2] crypto/qat: add aes-sha224-hmac capability to Intel QAT driver

[Deepak Kumar Jain]

From: "Jain, Deepak K" 

Added support of aes-sha224-hmac in Intel(R) QuickAssist driver

Signed-off-by: Deepak Kumar Jain 
---
 doc/guides/cryptodevs/qat.rst|  1 +
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 
 drivers/crypto/qat/qat_crypto.c  | 25 +-
 4 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 485abb4..7f630be 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -53,6 +53,7 @@ Cipher algorithms:
 Hash algorithms:

 * ``RTE_CRYPTO_AUTH_SHA1_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA224_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA256_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 4f7d784..040e250 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -40,6 +40,7 @@ New Features
   The QAT PMD was updated with changes including the following:

   * Added support for MD5_HMAC algorithm.
+  * Added support for SHA224-HMAC algorithm.


 Resolved Issues
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index 521a9c4..77e6548 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -71,6 +71,9 @@ static int qat_hash_get_state1_size(enum icp_qat_hw_auth_algo 
qat_hash_alg)
case ICP_QAT_HW_AUTH_ALGO_SHA1:
return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA1_STATE1_SZ,
QAT_HW_DEFAULT_ALIGNMENT);
+   case ICP_QAT_HW_AUTH_ALGO_SHA224:
+   return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA224_STATE1_SZ,
+   QAT_HW_DEFAULT_ALIGNMENT);
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA256_STATE1_SZ,
QAT_HW_DEFAULT_ALIGNMENT);
@@ -107,6 +110,8 @@ static int qat_hash_get_digest_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
switch (qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
return ICP_QAT_HW_SHA1_STATE1_SZ;
+   case ICP_QAT_HW_AUTH_ALGO_SHA224:
+   return ICP_QAT_HW_SHA224_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return ICP_QAT_HW_SHA256_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
@@ -129,6 +134,8 @@ static int qat_hash_get_block_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
switch (qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
return SHA_CBLOCK;
+   case ICP_QAT_HW_AUTH_ALGO_SHA224:
+   return SHA256_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
return SHA256_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
@@ -158,6 +165,17 @@ static int partial_hash_sha1(uint8_t *data_in, uint8_t 
*data_out)
return 0;
 }

+static int partial_hash_sha224(uint8_t *data_in, uint8_t *data_out)
+{
+   SHA256_CTX ctx;
+
+   if (!SHA224_Init())
+   return -EFAULT;
+   SHA256_Transform(, data_in);
+   rte_memcpy(data_out, , SHA256_DIGEST_LENGTH);
+   return 0;
+}
+
 static int partial_hash_sha256(uint8_t *data_in, uint8_t *data_out)
 {
SHA256_CTX ctx;
@@ -220,6 +238,13 @@ static int partial_hash_compute(enum icp_qat_hw_auth_algo 
hash_alg,
*hash_state_out_be32 =
rte_bswap32(*(((uint32_t *)digest)+i));
break;
+   case ICP_QAT_HW_AUTH_ALGO_SHA224:
+   if (partial_hash_sha224(data_in, digest))
+   return -EFAULT;
+   for (i = 0; i < digest_size >> 2; i++, hash_state_out_be32++)
+   *hash_state_out_be32 =
+   rte_bswap32(*(((uint32_t *)digest)+i));
+   break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
if (partial_hash_sha256(data_in, digest))
return -EFAULT;
@@ -575,6 +600,14 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
}
state2_size = RTE_ALIGN_CEIL(ICP_QAT_HW_SHA1_STATE2_SZ, 8);
break;
+   case ICP_QAT_HW_AUTH_ALGO_SHA224:
+   if (qat_alg_do_precomputes(ICP_QAT_HW_AUTH_ALGO_SHA224,
+   authkey, authkeylen, cdesc->cd_cur_ptr, _size)) {
+   PMD_DRV_LOG(ERR, "(SHA)precompute failed");
+   return -EFAULT;
+   }
+   state2_size = ICP_QAT_HW_SHA224_STATE2_SZ;
+   break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
if (qat_alg_do_precomputes(ICP_QAT_HW_AUTH_ALGO_SHA256,
   

[dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel QAT driver

[Deepak Kumar Jain]

This patchset adds support of aes-sha384-hmac in Intel(R) QuickAssist 
Technology driver.

This patchset depends on following patchset:
"crypto/qat: add aes-sha224-hmac capability to Intel QAT driver"
(http://dpdk.org/dev/patchwork/patch/15754/)

Jain, Deepak K (2):
  crypto/qat: add aes-sha224-hmac capability to Intel QAT driver
  app/test: add test cases for aes-sha224-hmac for Intel QAT driver

Changes from V1:
* Added new feature information in release_16_11.rst file.
* Added information about sha224-hmac in capabilities.

 app/test/test_cryptodev_aes.c|  6 +++--
 doc/guides/cryptodevs/qat.rst|  1 +
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 
 drivers/crypto/qat/qat_crypto.c  | 25 +-
 5 files changed, 63 insertions(+), 3 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v5 2/6] vhost: rewrite enqueue

[Maxime Coquelin]

On 09/09/2016 05:39 AM, Zhihong Wang wrote:
>
> +static inline void __attribute__((always_inline))
> +notify_guest(struct virtio_net *dev, struct vhost_virtqueue *vq)
> +{
>   rte_smp_wmb();
> -
> - *(volatile uint16_t *)>used->idx += count;
> - vq->last_used_idx += count;
> - vhost_log_used_vring(dev, vq,
> - offsetof(struct vring_used, idx),
> - sizeof(vq->used->idx));
> -
> - /* flush used->idx update before we read avail->flags. */
Please don't remove comments if not justified.
Here the comment is important, as it explains why the barrier is needed.
> + *(volatile uint16_t *)>used->idx = vq->last_used_idx;
> + vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
> + sizeof(vq->used->idx));
>   rte_mb();
> -
> - /* Kick the guest if necessary. */
>   if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
>   && (vq->callfd >= 0))
>   eventfd_write(vq->callfd, (eventfd_t)1);
> - return count;
>  }

[dpdk-dev] [PATCH v2 2/2] kni: add support for core_id param in single threaded mode

[Ferruh Yigit]

On 9/10/2016 2:50 PM, Vladyslav Buslov wrote:
> Allow binding KNI thread to specific core in single threaded mode
> by setting core_id and force_bind config parameters.
> 
> Signed-off-by: Vladyslav Buslov 
> ---
> 
> v2:
> * Fixed formatting.
> * Refactored kthread create/bind functionality into separate function.
> * Moved thread mode print into kni_init.
> * Added short description to KNI Programmer's Gude doc.
> * Fixed outdated mbuf processing description in KNI Programmer's Gude doc.
> 
>  doc/guides/prog_guide/kernel_nic_interface.rst |  5 +-
>  lib/librte_eal/linuxapp/kni/kni_misc.c | 72 
> +-
>  2 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst 
> b/doc/guides/prog_guide/kernel_nic_interface.rst
> index fac1960..0fdc307 100644
> --- a/doc/guides/prog_guide/kernel_nic_interface.rst
> +++ b/doc/guides/prog_guide/kernel_nic_interface.rst
> @@ -102,6 +102,9 @@ Refer to rte_kni_common.h in the DPDK source code for 
> more details.
>  
>  The physical addresses will be re-mapped into the kernel address space and 
> stored in separate KNI contexts.
>  
> +The affinity of kernel RX thread (both single and multi-threaded modes) is 
> controlled by force_bind and
> +core_id config parameters.
> +
>  The KNI interfaces can be deleted by a DPDK application dynamically after 
> being created.
>  Furthermore, all those KNI interfaces not deleted will be deleted on the 
> release operation
>  of the miscellaneous device (when the DPDK application is closed).
> @@ -128,7 +131,7 @@ Use Case: Ingress
>  On the DPDK RX side, the mbuf is allocated by the PMD in the RX thread 
> context.
>  This thread will enqueue the mbuf in the rx_q FIFO.
>  The KNI thread will poll all KNI active devices for the rx_q.
> -If an mbuf is dequeued, it will be converted to a sk_buff and sent to the 
> net stack via netif_rx().
> +If an mbuf is dequeued, it will be converted to a sk_buff and sent to the 
> net stack via netif_rx_ni().

Although this is small and correct modification, unrelated to this
patch. It is good to remove from this patch, and feel free to create a
separate patch if you want.

>  The dequeued mbuf must be freed, so the same pointer is sent back in the 
> free_q FIFO.
>  
>  The RX thread, in the same main loop, polls this FIFO and frees the mbuf 
> after dequeuing it.
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
> b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index 5e7cf21..c79f5a8 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -172,6 +172,11 @@ kni_init(void)
>   return -EINVAL;
>   }
>  
> + if (multiple_kthread_on == 0)
> + KNI_PRINT("Single kernel thread for all KNI devices\n");
> + else
> + KNI_PRINT("Multiple kernel thread mode enabled\n");
> +

Instead of fixing these in a second patch, why not do the correct one in
first patch? Or I think it is better to have a single patch instead of
two. What about squashing second patch into first?

>  #ifdef HAVE_SIMPLIFIED_PERNET_OPERATIONS
>   rc = register_pernet_subsys(_net_ops);
>  #else
> @@ -240,12 +245,6 @@ kni_open(struct inode *inode, struct file *file)
>   if (test_and_set_bit(KNI_DEV_IN_USE_BIT_NUM, >device_in_use))
>   return -EBUSY;
>  
> - /* Create kernel thread for single mode */
> - if (multiple_kthread_on == 0)
> - KNI_PRINT("Single kernel thread for all KNI devices\n");
> - else
> - KNI_PRINT("Multiple kernel thread mode enabled\n");
> -
>   file->private_data = get_net(net);
>   KNI_PRINT("/dev/kni opened\n");
>  
> @@ -391,6 +390,32 @@ kni_check_param(struct kni_dev *kni, struct 
> rte_kni_device_info *dev)
>   return 0;
>  }
>  
> +__printf(5, 6) static struct task_struct *
> +kni_run_thread(int (*threadfn)(void *data),
> + void *data,
> + uint8_t force_bind,
> + unsigned core_id,
> + const char namefmt[], ...)

Syntax should be updated.

> +{
> + struct task_struct *kni_thread = NULL;
> + char task_comm[TASK_COMM_LEN];
> + va_list args;
> +
> + va_start(args, namefmt);
> + vsnprintf(task_comm, sizeof(task_comm), namefmt, args);
> + va_end(args);

What about just using a "char *" and make things simpler, instead of
variable length parameters. Name can be kni_%s, for multi_thread %s is
kni->name, for single_thread %s is "single".

> +
> + kni_thread = kthread_create(threadfn, data, task_comm);
> + if (IS_ERR(kni_thread))
> + return NULL;
> +
> + if (force_bind)
> + kthread_bind(kni_thread, core_id);
> + wake_up_process(kni_thread);
> +
> + return kni_thread;
> +}
> +
>  static int
>  kni_ioctl_create(struct net *net,
>   unsigned int ioctl_num, unsigned long ioctl_param)
> @@ -419,8 +444,7 @@ kni_ioctl_create(struct net *net,
>   /**
>* Check if the cpu core id is 

[dpdk-dev] [PATCH v5 5/6] vhost: batch update used ring

[Maxime Coquelin]

On 09/09/2016 05:39 AM, Zhihong Wang wrote:
> This patch enables batch update of the used ring for better efficiency.
>
> Signed-off-by: Zhihong Wang 
> ---
> Changes in v4:
>
>  1. Free shadow used ring in the right place.
>
>  2. Add failure check for shadow used ring malloc.
>
>  lib/librte_vhost/vhost.c  | 20 --
>  lib/librte_vhost/vhost.h  |  4 +++
>  lib/librte_vhost/vhost_user.c | 31 +
>  lib/librte_vhost/virtio_net.c | 64 
> +++
>  4 files changed, 101 insertions(+), 18 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index 46095c3..cb31cdd 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -119,10 +119,26 @@ cleanup_device(struct virtio_net *dev, int destroy)
>  static void
>  free_device(struct virtio_net *dev)
>  {
> + struct vhost_virtqueue *vq_0;
> + struct vhost_virtqueue *vq_1;
>   uint32_t i;
>
> - for (i = 0; i < dev->virt_qp_nb; i++)
> - rte_free(dev->virtqueue[i * VIRTIO_QNUM]);
> + for (i = 0; i < dev->virt_qp_nb; i++) {
> + vq_0 = dev->virtqueue[i * VIRTIO_QNUM];
> + if (vq_0->shadow_used_ring) {
> + rte_free(vq_0->shadow_used_ring);
> + vq_0->shadow_used_ring = NULL;
> + }
> +
> + vq_1 = dev->virtqueue[i * VIRTIO_QNUM + 1];
> + if (vq_1->shadow_used_ring) {
> + rte_free(vq_1->shadow_used_ring);
> + vq_1->shadow_used_ring = NULL;
> + }
> +
> + /* malloc together, free together */
> + rte_free(vq_0);
> + }
>
>   rte_free(dev);
>  }
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index 9707dfc..381dc27 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -85,6 +85,10 @@ struct vhost_virtqueue {
>
>   /* Physical address of used ring, for logging */
>   uint64_tlog_guest_addr;
> +
> + /* Shadow used ring for performance */
> + struct vring_used_elem  *shadow_used_ring;
> + uint32_tshadow_used_idx;
>  } __rte_cache_aligned;
>
>  /* Old kernels have no such macro defined */
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index eee99e9..d7cf1ed 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -193,7 +193,21 @@ static int
>  vhost_user_set_vring_num(struct virtio_net *dev,
>struct vhost_vring_state *state)
>  {
> - dev->virtqueue[state->index]->size = state->num;
> + struct vhost_virtqueue *vq;
> +
> + vq = dev->virtqueue[state->index];
> + vq->size = state->num;
> + if (!vq->shadow_used_ring) {
> + vq->shadow_used_ring = rte_malloc(NULL,
> + vq->size * sizeof(struct vring_used_elem),
> + RTE_CACHE_LINE_SIZE);
> + if (!vq->shadow_used_ring) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Failed to allocate memory"
> + " for shadow used ring.\n");
> + return -1;
> + }
> + }
>
>   return 0;
>  }
> @@ -611,14 +625,21 @@ static int
>  vhost_user_get_vring_base(struct virtio_net *dev,
> struct vhost_vring_state *state)
>  {
> + struct vhost_virtqueue *vq;
> +
>   /* We have to stop the queue (virtio) if it is running. */
>   if (dev->flags & VIRTIO_DEV_RUNNING) {
>   dev->flags &= ~VIRTIO_DEV_RUNNING;
>   notify_ops->destroy_device(dev->vid);
>   }
>
> + vq = dev->virtqueue[state->index];
>   /* Here we are safe to get the last used index */
> - state->num = dev->virtqueue[state->index]->last_used_idx;
> + state->num = vq->last_used_idx;
> + if (vq->shadow_used_ring) {
> + rte_free(vq->shadow_used_ring);
> + vq->shadow_used_ring = NULL;
> + }
>
>   RTE_LOG(INFO, VHOST_CONFIG,
>   "vring base idx:%d file:%d\n", state->index, state->num);
> @@ -627,10 +648,10 @@ vhost_user_get_vring_base(struct virtio_net *dev,
>* sent and only sent in vhost_vring_stop.
>* TODO: cleanup the vring, it isn't usable since here.
>*/
> - if (dev->virtqueue[state->index]->kickfd >= 0)
> - close(dev->virtqueue[state->index]->kickfd);
> + if (vq->kickfd >= 0)
> + close(vq->kickfd);
>
> - dev->virtqueue[state->index]->kickfd = VIRTIO_UNINITIALIZED_EVENTFD;
> + vq->kickfd = VIRTIO_UNINITIALIZED_EVENTFD;
>
>   return 0;
>  }
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index b38f18f..e9f6353 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -134,17 +134,52 @@ virtio_enqueue_offload(struct rte_mbuf *m_buf, struct 
> 

[dpdk-dev] [PATCH v5 2/6] vhost: rewrite enqueue

[Maxime Coquelin]

Hi,

On 09/09/2016 05:39 AM, Zhihong Wang wrote:
> This patch implements the vhost logic from scratch into a single function
> designed for high performance and better maintainability.
>
> This is the baseline version of the new code, more optimization will be
> added in the following patches in this patch set.
>
> Signed-off-by: Zhihong Wang 
> ---
> Changes in v5:
>
>  1. Rebase to the latest branch.
>
>  2. Rename variables to keep consistent in naming style.
>
>  3. Small changes like return value adjustment and vertical alignment.
>
> ---
> Changes in v4:
>
>  1. Refactor the code for clearer logic.
>
>  2. Add PRINT_PACKET for debugging.
>
> ---
> Changes in v3:
>
>  1. Rewrite enqueue and delete the obsolete in the same patch.
>
>  lib/librte_vhost/virtio_net.c | 514 
> --
>  1 file changed, 138 insertions(+), 376 deletions(-)
>
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index 0d6e7d9..6f63968 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -91,7 +91,7 @@ is_valid_virt_queue_idx(uint32_t idx, int is_tx, uint32_t 
> qp_nb)
>   return (is_tx ^ (idx & 1)) == 0 && idx < qp_nb * VIRTIO_QNUM;
>  }
>
> -static void
> +static inline void __attribute__((always_inline))
>  virtio_enqueue_offload(struct rte_mbuf *m_buf, struct virtio_net_hdr 
> *net_hdr)
>  {
>   if (m_buf->ol_flags & PKT_TX_L4_MASK) {
> @@ -112,6 +112,10 @@ virtio_enqueue_offload(struct rte_mbuf *m_buf, struct 
> virtio_net_hdr *net_hdr)
>   cksum));
>   break;
>   }
> + } else {
> + net_hdr->flags   = 0;
> + net_hdr->csum_start  = 0;
> + net_hdr->csum_offset = 0;
>   }
>
>   if (m_buf->ol_flags & PKT_TX_TCP_SEG) {
> @@ -122,439 +126,197 @@ virtio_enqueue_offload(struct rte_mbuf *m_buf, struct 
> virtio_net_hdr *net_hdr)
>   net_hdr->gso_size = m_buf->tso_segsz;
>   net_hdr->hdr_len = m_buf->l2_len + m_buf->l3_len
>   + m_buf->l4_len;
> + } else {
> + net_hdr->gso_type = 0;
> + net_hdr->hdr_len  = 0;
> + net_hdr->gso_size = 0;
>   }
>  }
>
> -static inline void
> -copy_virtio_net_hdr(struct virtio_net *dev, uint64_t desc_addr,
> - struct virtio_net_hdr_mrg_rxbuf hdr)
> +static inline void __attribute__((always_inline))
> +update_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
> + uint32_t desc_chain_head, uint32_t desc_chain_len)
>  {
> - if (dev->vhost_hlen == sizeof(struct virtio_net_hdr_mrg_rxbuf))
> - *(struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc_addr = hdr;
> - else
> - *(struct virtio_net_hdr *)(uintptr_t)desc_addr = hdr.hdr;
> + uint32_t used_idx = vq->last_used_idx & (vq->size - 1);
> +
> + vq->used->ring[used_idx].id = desc_chain_head;
> + vq->used->ring[used_idx].len = desc_chain_len;
> + vq->last_used_idx++;
> + vhost_log_used_vring(dev, vq, offsetof(struct vring_used,
> + ring[used_idx]),
> + sizeof(vq->used->ring[used_idx]));
>  }
>
>  static inline int __attribute__((always_inline))
> -copy_mbuf_to_desc(struct virtio_net *dev, struct vhost_virtqueue *vq,
> -   struct rte_mbuf *m, uint16_t desc_idx)
> +enqueue_packet(struct virtio_net *dev, struct vhost_virtqueue *vq,
> + uint16_t avail_idx, struct rte_mbuf *mbuf,
> + uint32_t is_mrg_rxbuf)
>  {
> - uint32_t desc_avail, desc_offset;
> - uint32_t mbuf_avail, mbuf_offset;
> - uint32_t cpy_len;
> + struct virtio_net_hdr_mrg_rxbuf *virtio_hdr;
>   struct vring_desc *desc;
>   uint64_t desc_addr;
> - struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> + uint32_t desc_chain_head;
> + uint32_t desc_chain_len;
> + uint32_t desc_current;
> + uint32_t desc_offset;
> + uint32_t mbuf_len;
> + uint32_t mbuf_avail;
> + uint32_t cpy_len;
> + uint32_t num_buffers = 0;
>
> - desc = >desc[desc_idx];
> + /* start with the first mbuf of the packet */
> + mbuf_len = rte_pktmbuf_data_len(mbuf);
> + mbuf_avail = mbuf_len;
> +
> + /* get the current desc */
> + desc_current = vq->avail->ring[(vq->last_used_idx) & (vq->size - 1)];
> + desc_chain_head = desc_current;
> + desc = >desc[desc_current];
>   desc_addr = gpa_to_vva(dev, desc->addr);
> - /*
> -  * Checking of 'desc_addr' placed outside of 'unlikely' macro to avoid
> -  * performance issue with some versions of gcc (4.8.4 and 5.3.0) which
> -  * otherwise stores offset on the stack instead of in a register.
> -  */
> - if (unlikely(desc->len < dev->vhost_hlen) || !desc_addr)
> - return -1;
> + if (unlikely(!desc_addr))
> + goto error;
>
> - 

[dpdk-dev] [PATCH v3] net/i40e: fix parsing QinQ packets type issue

[Beilei Xing]

Previously, PTYPE filed in the RX descriptors is not set properly
for QinQ packets, wrong PTYPE is generated because outer Tag did
not have ORT/PIT configured. Fix this issue by configuring ORT/PIT.
Otherwise, this patch changes bitmask of outer VLAN tag in L2 header
to support RSS and flow director for QinQ.

Fixes: 4861cde46116 ("i40e: new poll mode driver")
Fixes: 4072d503aaa5 ("i40e: fix VLAN bitmasks for input set")

Signed-off-by: Beilei Xing 
---
 drivers/net/i40e/i40e_ethdev.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 55c4887..be4b530 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -202,7 +202,7 @@
 /* Source MAC address */
 #define I40E_REG_INSET_L2_SMAC   0x1C00ULL
 /* Outer (S-Tag) VLAN tag in the outer L2 header */
-#define I40E_REG_INSET_L2_OUTER_VLAN 0x0200ULL
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0400ULL
 /* Inner (C-Tag) or single VLAN tag in the outer L2 header */
 #define I40E_REG_INSET_L2_INNER_VLAN 0x0080ULL
 /* Single VLAN tag in the inner L2 header */
@@ -724,10 +724,6 @@ static struct rte_driver rte_i40e_driver = {
 PMD_REGISTER_DRIVER(rte_i40e_driver, i40e);
 DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);

-/*
- * Initialize registers for flexible payload, which should be set by NVM.
- * This should be removed from code once it is fixed in NVM.
- */
 #ifndef I40E_GLQF_ORT
 #define I40E_GLQF_ORT(_i)(0x00268900 + ((_i) * 4))
 #endif
@@ -735,8 +731,12 @@ DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);
 #define I40E_GLQF_PIT(_i)(0x00268C80 + ((_i) * 4))
 #endif

-static inline void i40e_flex_payload_reg_init(struct i40e_hw *hw)
+static inline void i40e_GLQF_reg_init(struct i40e_hw *hw)
 {
+   /*
+* Initialize registers for flexible payload, which should be set by 
NVM.
+* This should be removed from code once it is fixed in NVM.
+*/
I40E_WRITE_REG(hw, I40E_GLQF_ORT(18), 0x0030);
I40E_WRITE_REG(hw, I40E_GLQF_ORT(19), 0x0030);
I40E_WRITE_REG(hw, I40E_GLQF_ORT(26), 0x002B);
@@ -747,10 +747,12 @@ static inline void i40e_flex_payload_reg_init(struct 
i40e_hw *hw)
I40E_WRITE_REG(hw, I40E_GLQF_ORT(20), 0x0031);
I40E_WRITE_REG(hw, I40E_GLQF_ORT(23), 0x0031);
I40E_WRITE_REG(hw, I40E_GLQF_ORT(63), 0x002D);
-
-   /* GLQF_PIT Registers */
I40E_WRITE_REG(hw, I40E_GLQF_PIT(16), 0x7480);
I40E_WRITE_REG(hw, I40E_GLQF_PIT(17), 0x7440);
+
+   /* Initialize registers for parsing packet type of QinQ */
+   I40E_WRITE_REG(hw, I40E_GLQF_ORT(40), 0x0029);
+   I40E_WRITE_REG(hw, I40E_GLQF_PIT(9), 0x9420);
 }

 #define I40E_FLOW_CONTROL_ETHERTYPE  0x8808
@@ -1005,11 +1007,12 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
}

/*
-* To work around the NVM issue,initialize registers
-* for flexible payload by software.
-* It should be removed once issues are fixed in NVM.
+* To work around the NVM issue, initialize registers
+* for flexible payload and packet type of QinQ by
+* software. It should be removed once issues are fixed
+* in NVM.
 */
-   i40e_flex_payload_reg_init(hw);
+   i40e_GLQF_reg_init(hw);

/* Initialize the input set for filters (hash and fd) to default value 
*/
i40e_filter_input_set_init(pf);
-- 
2.5.0

[dpdk-dev] [PATCH] net/i40e: fix outer VLAN bitmask for input set

[Beilei Xing]

This patch changes bitmask of outer VLAN tag in L2 header to
support RSS and flow director for QinQ.

Fixes: 4072d503aaa5 ("i40e: fix VLAN bitmasks for input set")

Signed-off-by: Beilei Xing 
---
 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 59ff6dc..be4b530 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -202,7 +202,7 @@
 /* Source MAC address */
 #define I40E_REG_INSET_L2_SMAC   0x1C00ULL
 /* Outer (S-Tag) VLAN tag in the outer L2 header */
-#define I40E_REG_INSET_L2_OUTER_VLAN 0x0200ULL
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0400ULL
 /* Inner (C-Tag) or single VLAN tag in the outer L2 header */
 #define I40E_REG_INSET_L2_INNER_VLAN 0x0080ULL
 /* Single VLAN tag in the inner L2 header */
-- 
2.5.0

[dpdk-dev] [PATCH 1/4] libcrypto_pmd: initial implementation of SW crypto device

[Akhil Goyal]

On 8/26/2016 12:51 PM, Piotr Azarewicz wrote:

> +/** Provide session for operation */
> +static struct libcrypto_session *
> +get_session(struct libcrypto_qp *qp, struct rte_crypto_op *op)
> +{
> + struct libcrypto_session *sess = NULL;
> +
> + if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
> + /* get existing session */
> + if (!unlikely(op->sym->session == NULL ||
> + op->sym->session->dev_type !=
> + RTE_CRYPTODEV_LIBCRYPTO_PMD))
> + sess = (struct libcrypto_session *)
> + op->sym->session->_private;
> + } else  {
> + /* provide internal session */
> + void *_sess = NULL;
> +
> + if (!rte_mempool_get(qp->sess_mp, (void **)&_sess)) {
> + sess = (struct libcrypto_session *)
> + ((struct rte_cryptodev_sym_session *)_sess)
> + ->_private;
> +
> + if (unlikely(libcrypto_set_session_parameters(
> + sess, op->sym->xform) != 0)) {
> + rte_mempool_put(qp->sess_mp, _sess);
> + sess = NULL;
> + } else
> + op->sym->session = _sess;
> + }
> + }
> +
> + if (sess == NULL)
> + op->status = RTE_CRYPTO_OP_STATUS_INVALID_SESSION;
> +
> + return sess;
> +}
> +
> +/*
> + 
> *--
> + * Process Operations
> + 
> *--
> + */
> +
> +/** Process standard libcrypto cipher encryption */
> +static int
> +process_libcrypto_cipher_encrypt(uint8_t *src, uint8_t *dst,
> + uint8_t *iv, uint8_t *key, int srclen,
> + EVP_CIPHER_CTX *ctx, const EVP_CIPHER *algo)
> +{
> + int dstlen, totlen;
> +
> + if (EVP_EncryptInit_ex(ctx, algo, NULL, key, iv) <= 0)
> + goto process_cipher_encrypt_err;
[Akhil] this EVP_EncryptInit_ex() can be done for each session instead 
of each packet. This will improve the performance. Also if there is some 
change in the parameters later then it can be called again here with the 
updated parameters only.
Same comment is for all cases (hmac, auth, etc)
> +
> + if (EVP_EncryptUpdate(ctx, dst, , src, srclen) <= 0)
> + goto process_cipher_encrypt_err;
> +
> + if (EVP_EncryptFinal_ex(ctx, dst + dstlen, ) <= 0)
> + goto process_cipher_encrypt_err;
> +
> + return 0;
> +
> +process_cipher_encrypt_err:
> + LIBCRYPTO_LOG_ERR("Process libcrypto cipher encrypt failed");
> + return -EINVAL;
> +}
> +
> +/** Process standard libcrypto cipher decryption */
> +static int
> +process_libcrypto_cipher_decrypt(uint8_t *src, uint8_t *dst,
> + uint8_t *iv, uint8_t *key, int srclen,
> + EVP_CIPHER_CTX *ctx, const EVP_CIPHER *algo)
> +{
> + int dstlen, totlen;
> +
> + if (EVP_DecryptInit_ex(ctx, algo, NULL, key, iv) <= 0)
> + goto process_cipher_decrypt_err;
> +
> + if (EVP_CIPHER_CTX_set_padding(ctx, 0) <= 0)
> + goto process_cipher_decrypt_err;
> +
> + if (EVP_DecryptUpdate(ctx, dst, , src, srclen) <= 0)
> + goto process_cipher_decrypt_err;
> +
> + if (EVP_DecryptFinal_ex(ctx, dst + dstlen, ) <= 0)
> + goto process_cipher_decrypt_err;
> +
> + return 0;
> +
> +process_cipher_decrypt_err:
> + LIBCRYPTO_LOG_ERR("Process libcrypto cipher decrypt failed");
> + return -EINVAL;
> +}
> +
> +/** Process cipher des 3 ctr encryption, decryption algorithm */
> +static int
> +process_libcrypto_cipher_des3ctr(uint8_t *src, uint8_t *dst,
> + uint8_t *iv, uint8_t *key, int srclen, EVP_CIPHER_CTX *ctx)
> +{
> + uint8_t ebuf[8], ctr[8];
> + int unused, n;
> +
> + /* We use 3DES encryption also for decryption.
> +  * IV is not important for 3DES ecb
> +  */
> + if (EVP_EncryptInit_ex(ctx, EVP_des_ede3_ecb(), NULL, key, NULL) <= 0)
> + goto process_cipher_des3ctr_err;
> +
> + memcpy(ctr, iv, 8);
> + n = 0;
> +
> + while (n < srclen) {
> + if (n % 8 == 0) {
> + if (EVP_EncryptUpdate(ctx, (unsigned char *), 
> ,
> + (const unsigned char *), 8) <= 0)
> + goto process_cipher_des3ctr_err;
> + ctr_inc(ctr);
> + }
> + dst[n] = src[n] ^ ebuf[n % 8];
> + n++;
> + }
> +
> + return 0;
> +
> +process_cipher_des3ctr_err:
> + LIBCRYPTO_LOG_ERR("Process libcrypto cipher des 3 ede ctr failed");
> + return -EINVAL;
> +}
> +
> +/** Process auth gmac algorithm */
> +static int
> +process_libcrypto_auth_gmac(uint8_t *src, uint8_t *dst,
> + uint8_t *iv, 

[dpdk-dev] [PATCH v2 6/6] testpmd: add txprep engine

[Tomasz Kulasek]

This patch adds txprep engine to the testpmd application.

Txprep engine is intended to verify Tx preparation functionality
implemented in pmd driver.

It's based on the default "io" engine with the folowing changes:
 - Tx HW offloads are reset in incoming packet,
 - burst is passed to the Tx preparation function before tx burst,
 - added "txsplit" and "tso" functionality for outgoing packets.

Signed-off-by: Tomasz Kulasek 
---
 app/test-pmd/Makefile  |3 +-
 app/test-pmd/testpmd.c |3 +
 app/test-pmd/testpmd.h |4 +-
 app/test-pmd/txprep.c  |  412 
 4 files changed, 420 insertions(+), 2 deletions(-)
 create mode 100644 app/test-pmd/txprep.c

diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 2a0b5a5..3f9ad1c 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -49,6 +49,7 @@ SRCS-y += parameters.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline.c
 SRCS-y += config.c
 SRCS-y += iofwd.c
+SRCS-$(CONFIG_RTE_ETHDEV_TX_PREP) += txprep.c
 SRCS-y += macfwd.c
 SRCS-y += macswap.c
 SRCS-y += flowgen.c
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1428974..9b6c475 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -152,6 +152,9 @@ struct fwd_engine * fwd_engines[] = {
_only_engine,
_only_engine,
_fwd_engine,
+#ifdef RTE_ETHDEV_TX_PREP
+   _fwd_engine,
+#endif
_echo_engine,
 #ifdef RTE_LIBRTE_IEEE1588
_fwd_engine,
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 2b281cc..f800846 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -239,7 +239,9 @@ extern struct fwd_engine icmp_echo_engine;
 #ifdef RTE_LIBRTE_IEEE1588
 extern struct fwd_engine ieee1588_fwd_engine;
 #endif
-
+#ifdef RTE_ETHDEV_TX_PREP
+extern struct fwd_engine txprep_fwd_engine;
+#endif
 extern struct fwd_engine * fwd_engines[]; /**< NULL terminated array. */

 /**
diff --git a/app/test-pmd/txprep.c b/app/test-pmd/txprep.c
new file mode 100644
index 000..688927e
--- /dev/null
+++ b/app/test-pmd/txprep.c
@@ -0,0 +1,412 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "testpmd.h"
+
+/* We cannot use rte_cpu_to_be_16() on a constant in a switch/case */
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+#define _htons(x) ((uint16_t)x) & 0x00ffU) << 8) | (((x) & 0xff00U) >> 8)))
+#else
+#define _htons(x) (x)
+#endif
+
+/*
+ * Helper function.
+ * Performs actual copying.
+ * Returns number of segments in the destination mbuf on success,
+ * or negative error code on failure.
+ */
+static int
+mbuf_copy_split(const struct rte_mbuf *ms, struct rte_mbuf 

[dpdk-dev] [PATCH v2 5/6] ixgbe: add Tx preparation

[Tomasz Kulasek]

Signed-off-by: Tomasz Kulasek 
---
 drivers/net/ixgbe/ixgbe_ethdev.c |3 ++
 drivers/net/ixgbe/ixgbe_ethdev.h |8 +++-
 drivers/net/ixgbe/ixgbe_rxtx.c   |   83 +-
 drivers/net/ixgbe/ixgbe_rxtx.h   |2 +
 4 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index fb618ef..1509979 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -515,6 +515,8 @@ static const struct rte_eth_desc_lim tx_desc_lim = {
.nb_max = IXGBE_MAX_RING_DESC,
.nb_min = IXGBE_MIN_RING_DESC,
.nb_align = IXGBE_TXD_ALIGN,
+   .nb_seg_max = IXGBE_TX_MAX_SEG,
+   .nb_mtu_seg_max = IXGBE_TX_MAX_SEG,
 };

 static const struct eth_dev_ops ixgbe_eth_dev_ops = {
@@ -1101,6 +1103,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->dev_ops = _eth_dev_ops;
eth_dev->rx_pkt_burst = _recv_pkts;
eth_dev->tx_pkt_burst = _xmit_pkts;
+   eth_dev->tx_pkt_prep = _prep_pkts;

/*
 * For secondary processes, we don't initialise any further as primary
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 4ff6338..09d96de 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -396,6 +396,12 @@ uint16_t ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,
 uint16_t ixgbe_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);

+uint16_t ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
+uint16_t ixgbe_prep_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
 int ixgbe_dev_rss_hash_update(struct rte_eth_dev *dev,
  struct rte_eth_rss_conf *rss_conf);

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 8a306b0..87defa0 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   Copyright 2014 6WIND S.A.
  *   All rights reserved.
  *
@@ -71,6 +71,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "ixgbe_logs.h"
 #include "base/ixgbe_api.h"
@@ -906,6 +907,84 @@ end_of_tx:

 /*
  *
+ *  TX prep functions
+ *
+ **/
+uint16_t
+ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
+{
+   int i, ret;
+   struct rte_mbuf *m;
+   struct ixgbe_tx_queue *txq = (struct ixgbe_tx_queue *)tx_queue;
+
+   for (i = 0; i < nb_pkts; i++) {
+   m = tx_pkts[i];
+
+   /**
+* Check if packet meets requirements for number of segments
+*
+* NOTE: for ixgbe it's always (40 - WTHRESH) for both TSO and 
non-TSO
+*/
+
+   if (m->nb_segs > IXGBE_TX_MAX_SEG - txq->wthresh) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+   if ((m->ol_flags & PKT_TX_OFFLOAD_MASK) !=
+   (m->ol_flags & IXGBE_TX_OFFLOAD_MASK)) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+   ret = rte_validate_tx_offload(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+#endif
+   ret = rte_phdr_cksum_fix(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+   }
+
+   return i;
+}
+
+/* ixgbe simple path as well as vector TX doesn't support tx offloads */
+uint16_t
+ixgbe_prep_pkts_simple(void *tx_queue __rte_unused, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   int i;
+   struct rte_mbuf *m;
+   uint64_t ol_flags;
+
+   for (i = 0; i < nb_pkts; i++) {
+   m = tx_pkts[i];
+   ol_flags = m->ol_flags;
+
+   /* simple tx path doesn't support multi-segments */
+   if (m->nb_segs != 1) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+   /* For simple path (simple and vector) no tx offloads are 
supported */
+   if (ol_flags & PKT_TX_OFFLOAD_MASK) {
+

[dpdk-dev] [PATCH v2 4/6] i40e: add Tx preparation

[Tomasz Kulasek]

Signed-off-by: Tomasz Kulasek 
---
 drivers/net/i40e/i40e_ethdev.c |3 ++
 drivers/net/i40e/i40e_rxtx.c   |   98 +++-
 drivers/net/i40e/i40e_rxtx.h   |   10 
 3 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..52a2abb 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -948,6 +948,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
dev->dev_ops = _eth_dev_ops;
dev->rx_pkt_burst = i40e_recv_pkts;
dev->tx_pkt_burst = i40e_xmit_pkts;
+   dev->tx_pkt_prep = i40e_prep_pkts;

/* for secondary processes, we don't initialise any further as primary
 * has already done this work. Only check we don't need a different
@@ -2614,6 +2615,8 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.nb_max = I40E_MAX_RING_DESC,
.nb_min = I40E_MIN_RING_DESC,
.nb_align = I40E_ALIGN_RING_DESC,
+   .nb_seg_max = I40E_TX_MAX_SEG,
+   .nb_mtu_seg_max = I40E_TX_MAX_MTU_SEG,
};

if (pf->flags & I40E_FLAG_VMDQ) {
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 554d167..1cd34f7 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -50,6 +50,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "i40e_logs.h"
 #include "base/i40e_prototype.h"
@@ -79,6 +81,14 @@
PKT_TX_TCP_SEG | \
PKT_TX_OUTER_IP_CKSUM)

+#define I40E_TX_OFFLOAD_MASK (  \
+   PKT_TX_IP_CKSUM |   \
+   PKT_TX_L4_MASK |\
+   PKT_TX_OUTER_IP_CKSUM | \
+   PKT_TX_TCP_SEG |\
+   PKT_TX_QINQ_PKT |   \
+   PKT_TX_VLAN_PKT)
+
 static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
  struct rte_mbuf **tx_pkts,
  uint16_t nb_pkts);
@@ -1930,6 +1940,90 @@ i40e_xmit_pkts_simple(void *tx_queue,
return nb_tx;
 }

+/*
+ *
+ *  TX prep functions
+ *
+ **/
+uint16_t
+i40e_prep_pkts(void *tx_queue __rte_unused, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   int i, ret;
+   uint64_t ol_flags;
+   struct rte_mbuf *m;
+
+   for (i = 0; i < nb_pkts; i++) {
+   m = tx_pkts[i];
+   ol_flags = m->ol_flags;
+
+   /**
+* m->nb_segs is uint8_t, so m->nb_segs is always less than
+* I40E_TX_MAX_SEG.
+* We check only a condition for m->nb_segs > 
I40E_TX_MAX_MTU_SEG.
+*/
+   if (!(ol_flags & PKT_TX_TCP_SEG)) {
+   if (m->nb_segs > I40E_TX_MAX_MTU_SEG) {
+   rte_errno = -1;
+   return i;
+   }
+   } else if ((m->tso_segsz < I40E_MIN_TSO_MSS) ||
+   (m->tso_segsz > I40E_MAX_TSO_MSS)) {
+   /* MSS outside the range (256B - 9674B) are considered 
malicious */
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+   if ((ol_flags & PKT_TX_OFFLOAD_MASK) !=
+   (ol_flags & I40E_TX_OFFLOAD_MASK)) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+   ret = rte_validate_tx_offload(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+#endif
+   ret = rte_phdr_cksum_fix(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+   }
+   return i;
+}
+
+/* i40e simple path doesn't support tx offloads */
+uint16_t
+i40e_prep_pkts_simple(void *tx_queue __rte_unused, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   int i;
+   uint64_t ol_flags;
+   struct rte_mbuf *m;
+
+   for (i = 0; i < nb_pkts; i++) {
+   m = tx_pkts[i];
+   ol_flags = m->ol_flags;
+
+   /* For simple path (simple and vector) no tx offloads are 
supported */
+   if (m->nb_segs > I40E_TX_MAX_MTU_SEG) {
+   rte_errno = -1;
+   return i;
+   }
+
+  

[dpdk-dev] [PATCH v2 3/6] fm10k: add Tx preparation

[Tomasz Kulasek]

Signed-off-by: Tomasz Kulasek 
---
 drivers/net/fm10k/fm10k.h|9 +
 drivers/net/fm10k/fm10k_ethdev.c |5 +++
 drivers/net/fm10k/fm10k_rxtx.c   |   77 +-
 3 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index 05aa1a2..83d2bfb 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -69,6 +69,9 @@
 #define FM10K_MAX_RX_DESC  (FM10K_MAX_RX_RING_SZ / sizeof(union fm10k_rx_desc))
 #define FM10K_MAX_TX_DESC  (FM10K_MAX_TX_RING_SZ / sizeof(struct 
fm10k_tx_desc))

+#define FM10K_TX_MAX_SEG UINT8_MAX
+#define FM10K_TX_MAX_MTU_SEG UINT8_MAX
+
 /*
  * byte aligment for HW RX data buffer
  * Datasheet requires RX buffer addresses shall either be 512-byte aligned or
@@ -356,6 +359,12 @@ fm10k_dev_rx_descriptor_done(void *rx_queue, uint16_t 
offset);
 uint16_t fm10k_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);

+uint16_t fm10k_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
+uint16_t fm10k_prep_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
 int fm10k_rxq_vec_setup(struct fm10k_rx_queue *rxq);
 int fm10k_rx_vec_condition_check(struct rte_eth_dev *);
 void fm10k_rx_queue_release_mbufs_vec(struct fm10k_rx_queue *rxq);
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 01f4a72..c9f450e 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1441,6 +1441,8 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
.nb_max = FM10K_MAX_TX_DESC,
.nb_min = FM10K_MIN_TX_DESC,
.nb_align = FM10K_MULT_TX_DESC,
+   .nb_seg_max = FM10K_TX_MAX_SEG,
+   .nb_mtu_seg_max = FM10K_TX_MAX_MTU_SEG,
};

dev_info->speed_capa = ETH_LINK_SPEED_1G | ETH_LINK_SPEED_2_5G |
@@ -2749,8 +2751,10 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
fm10k_txq_vec_setup(txq);
}
dev->tx_pkt_burst = fm10k_xmit_pkts_vec;
+   dev->tx_pkt_prep = fm10k_prep_pkts_simple;
} else {
dev->tx_pkt_burst = fm10k_xmit_pkts;
+   dev->tx_pkt_prep = fm10k_prep_pkts;
PMD_INIT_LOG(DEBUG, "Use regular Tx func");
}
 }
@@ -2829,6 +2833,7 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
dev->dev_ops = _eth_dev_ops;
dev->rx_pkt_burst = _recv_pkts;
dev->tx_pkt_burst = _xmit_pkts;
+   dev->tx_pkt_prep = _prep_pkts;

/* only initialize in the primary process */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 5b2d04b..a87b06f 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2013-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -35,6 +35,7 @@

 #include 
 #include 
+#include 
 #include "fm10k.h"
 #include "base/fm10k_type.h"

@@ -65,6 +66,12 @@ static inline void dump_rxd(union fm10k_rx_desc *rxd)
 }
 #endif

+#define FM10K_TX_OFFLOAD_MASK (  \
+   PKT_TX_VLAN_PKT |\
+   PKT_TX_IP_CKSUM |\
+   PKT_TX_L4_MASK | \
+   PKT_TX_TCP_SEG)
+
 /* @note: When this function is changed, make corresponding change to
  * fm10k_dev_supported_ptypes_get()
  */
@@ -583,3 +590,71 @@ fm10k_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,

return count;
 }
+
+uint16_t
+fm10k_prep_pkts(void *tx_queue __rte_unused, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   int i, ret;
+   struct rte_mbuf *m;
+
+   for (i = 0; i < nb_pkts; i++) {
+   m = tx_pkts[i];
+
+   if ((m->ol_flags & PKT_TX_TCP_SEG) &&
+   (m->tso_segsz < FM10K_TSO_MINMSS)) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+   if ((m->ol_flags & PKT_TX_OFFLOAD_MASK) !=
+   (m->ol_flags & FM10K_TX_OFFLOAD_MASK)) {
+   rte_errno = -EINVAL;
+   return i;
+   }
+
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+   ret = rte_validate_tx_offload(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+#endif
+   ret = rte_phdr_cksum_fix(m);
+   if (ret != 0) {
+   rte_errno = ret;
+   return i;
+   }
+   }
+
+   return i;
+}
+
+/* fm10k vector TX path doesn't support tx offloads */
+uint16_t

[dpdk-dev] [PATCH v2 1/6] ethdev: add Tx preparation

[Tomasz Kulasek]

Added API for `rte_eth_tx_prep`

uint16_t rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id,
struct rte_mbuf **tx_pkts, uint16_t nb_pkts)

Added fields to the `struct rte_eth_desc_lim`:

uint16_t nb_seg_max;
/**< Max number of segments per whole packet. */

uint16_t nb_mtu_seg_max;
/**< Max number of segments per one MTU */

Created `rte_pkt.h` header with common used functions:

int rte_validate_tx_offload(struct rte_mbuf *m)
to validate general requirements for tx offload in packet such a
flag completness. In current implementation this funtion is called
optionaly when RTE_LIBRTE_ETHDEV_DEBUG is enabled.

int rte_phdr_cksum_fix(struct rte_mbuf *m)
to fix pseudo header checksum for TSO and non-TSO tcp/udp packets
before hardware tx checksum offload.
 - for non-TSO tcp/udp packets full pseudo-header checksum is
   counted and set.
 - for TSO the IP payload length is not included.

Signed-off-by: Tomasz Kulasek 
---
 config/common_base|1 +
 lib/librte_ether/rte_ethdev.h |   85 ++
 lib/librte_mbuf/rte_mbuf.h|8 +++
 lib/librte_net/Makefile   |2 +-
 lib/librte_net/rte_pkt.h  |  132 +
 5 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_net/rte_pkt.h

diff --git a/config/common_base b/config/common_base
index 7830535..7ada9e0 100644
--- a/config/common_base
+++ b/config/common_base
@@ -120,6 +120,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
 CONFIG_RTE_LIBRTE_IEEE1588=n
 CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
 CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
+CONFIG_RTE_ETHDEV_TX_PREP=y

 #
 # Support NIC bypass logic
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b0fe033..4fa674d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -182,6 +182,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 #include "rte_ether.h"
 #include "rte_eth_ctrl.h"
 #include "rte_dev_info.h"
@@ -696,6 +697,8 @@ struct rte_eth_desc_lim {
uint16_t nb_max;   /**< Max allowed number of descriptors. */
uint16_t nb_min;   /**< Min allowed number of descriptors. */
uint16_t nb_align; /**< Number of descriptors should be aligned to. */
+   uint16_t nb_seg_max; /**< Max number of segments per whole packet. 
*/
+   uint16_t nb_mtu_seg_max; /**< Max number of segments per one MTU */
 };

 /**
@@ -1181,6 +1184,11 @@ typedef uint16_t (*eth_tx_burst_t)(void *txq,
   uint16_t nb_pkts);
 /**< @internal Send output packets on a transmit queue of an Ethernet device. 
*/

+typedef uint16_t (*eth_tx_prep_t)(void *txq,
+  struct rte_mbuf **tx_pkts,
+  uint16_t nb_pkts);
+/**< @internal Prepare output packets on a transmit queue of an Ethernet 
device. */
+
 typedef int (*flow_ctrl_get_t)(struct rte_eth_dev *dev,
   struct rte_eth_fc_conf *fc_conf);
 /**< @internal Get current flow control parameter on an Ethernet device */
@@ -1626,6 +1634,7 @@ enum rte_eth_dev_type {
 struct rte_eth_dev {
eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
+   eth_tx_prep_t tx_pkt_prep; /**< Pointer to PMD transmit prepare 
function. */
struct rte_eth_dev_data *data;  /**< Pointer to device data */
const struct eth_driver *driver;/**< Driver for this device */
const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
@@ -2833,6 +2842,82 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, 
nb_pkts);
 }

+/**
+ * Process a burst of output packets on a transmit queue of an Ethernet device.
+ *
+ * The rte_eth_tx_prep() function is invoked to prepare output packets to be
+ * transmitted on the output queue *queue_id* of the Ethernet device designated
+ * by its *port_id*.
+ * The *nb_pkts* parameter is the number of packets to be prepared which are
+ * supplied in the *tx_pkts* array of *rte_mbuf* structures, each of them
+ * allocated from a pool created with rte_pktmbuf_pool_create().
+ * For each packet to send, the rte_eth_tx_prep() function performs
+ * the following operations:
+ *
+ * - Check if packet meets devices requirements for tx offloads.
+ *
+ * - Check limitations about number of segments.
+ *
+ * - Check additional requirements when debug is enabled.
+ *
+ * - Update and/or reset required checksums when tx offload is set for packet.
+ *
+ * The rte_eth_tx_prep() function returns the number of packets ready to be
+ * sent. A return value equal to *nb_pkts* means that all packets are valid and
+ * ready to be sent.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet 

[dpdk-dev] [PATCH v2 0/6] add Tx preparation

[Tomasz Kulasek]

As discussed in that thread:

http://dpdk.org/ml/archives/dev/2015-September/023603.html

Different NIC models depending on HW offload requested might impose
different requirements on packets to be TX-ed in terms of:

 - Max number of fragments per packet allowed
 - Max number of fragments per TSO segments
 - The way pseudo-header checksum should be pre-calculated
 - L3/L4 header fields filling
 - etc.


MOTIVATION:
---

1) Some work cannot (and didn't should) be done in rte_eth_tx_burst.
   However, this work is sometimes required, and now, it's an
   application issue.

2) Different hardware may have different requirements for TX offloads,
   other subset can be supported and so on.

3) Some parameters (e.g. number of segments in ixgbe driver) may hung
   device. These parameters may be vary for different devices.

   For example i40e HW allows 8 fragments per packet, but that is after
   TSO segmentation. While ixgbe has a 38-fragment pre-TSO limit.

4) Fields in packet may require different initialization (like e.g. will
   require pseudo-header checksum precalculation, sometimes in a
   different way depending on packet type, and so on). Now application
   needs to care about it.

5) Using additional API (rte_eth_tx_prep) before rte_eth_tx_burst let to
   prepare packet burst in acceptable form for specific device.

6) Some additional checks may be done in debug mode keeping tx_burst
   implementation clean.


PROPOSAL:
-

To help user to deal with all these varieties we propose to:

1) Introduce rte_eth_tx_prep() function to do necessary preparations of
   packet burst to be safely transmitted on device for desired HW
   offloads (set/reset checksum field according to the hardware
   requirements) and check HW constraints (number of segments per
   packet, etc).

   While the limitations and requirements may differ for devices, it
   requires to extend rte_eth_dev structure with new function pointer
   "tx_pkt_prep" which can be implemented in the driver to prepare and
   verify packets, in devices specific way, before burst, what should to
   prevent application to send malformed packets.

2) Also new fields will be introduced in rte_eth_desc_lim: 
   nb_seg_max and nb_mtu_seg_max, providing an information about max
   segments in TSO and non-TSO packets acceptable by device.

   This information is useful for application to not create/limit
   malicious packet.


APPLICATION (CASE OF USE):
--

1) Application should to initialize burst of packets to send, set
   required tx offload flags and required fields, like l2_len, l3_len,
   l4_len, and tso_segsz

2) Application passes burst to the rte_eth_tx_prep to check conditions
   required to send packets through the NIC.

3) The result of rte_eth_tx_prep can be used to send valid packets
   and/or restore invalid if function fails.

e.g.

for (i = 0; i < nb_pkts; i++) {

/* initialize or process packet */

bufs[i]->tso_segsz = 800;
bufs[i]->ol_flags = PKT_TX_TCP_SEG | PKT_TX_IPV4
| PKT_TX_IP_CKSUM;
bufs[i]->l2_len = sizeof(struct ether_hdr);
bufs[i]->l3_len = sizeof(struct ipv4_hdr);
bufs[i]->l4_len = sizeof(struct tcp_hdr);
}

/* Prepare burst of TX packets */
nb_prep = rte_eth_tx_prep(port, 0, bufs, nb_pkts);

if (nb_prep < nb_pkts) {
printf("tx_prep failed\n");

/* nb_prep indicates here first invalid packet. rte_eth_tx_prep
 * can be used on remaining packets to find another ones.
 */

}

/* Send burst of TX packets */
nb_tx = rte_eth_tx_burst(port, 0, bufs, nb_prep);

/* Free any unsent packets. */


v2 changes:
 - rte_eth_tx_prep() returns number of packets when device doesn't
   support tx_prep functionality,
 - introduced CONFIG_RTE_ETHDEV_TX_PREP allowing to turn off tx_prep

Tomasz Kulasek (6):
  ethdev: add Tx preparation
  e1000: add Tx preparation
  fm10k: add Tx preparation
  i40e: add Tx preparation
  ixgbe: add Tx preparation
  testpmd: add txprep engine

 app/test-pmd/Makefile|3 +-
 app/test-pmd/testpmd.c   |3 +
 app/test-pmd/testpmd.h   |4 +-
 app/test-pmd/txprep.c|  412 ++
 config/common_base   |1 +
 drivers/net/e1000/e1000_ethdev.h |   11 +
 drivers/net/e1000/em_ethdev.c|5 +-
 drivers/net/e1000/em_rxtx.c  |   46 -
 drivers/net/e1000/igb_ethdev.c   |4 +
 drivers/net/e1000/igb_rxtx.c |   50 -
 drivers/net/fm10k/fm10k.h|9 +
 drivers/net/fm10k/fm10k_ethdev.c |5 +
 drivers/net/fm10k/fm10k_rxtx.c   |   77 ++-
 drivers/net/i40e/i40e_ethdev.c   |3 +
 drivers/net/i40e/i40e_rxtx.c |   98 -
 drivers/net/i40e/i40e_rxtx.h |   10 +
 drivers/net/ixgbe/ixgbe_ethdev.c |3 +
 

[dpdk-dev] DPDK Userspace Summit Dublin 2016 (October 20th & 21st)

[Butler, Siobhan A]

Dear Community,
I am delighted to let you know our registration for this year's summit is very 
close to capacity already! If you are intending on attending please register 
(www.dpdksummit.com) as soon as possible to avoid 
disappointment.
If you have registered and cannot attend we would be very grateful if you could 
let us know so that we can fill the space.
Very excited to see you in October,
Siobh?n

[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework

[Pankaj Chauhan]

On 9/11/2016 5:51 PM, Yuanhan Liu wrote:
> On Mon, Sep 05, 2016 at 04:24:29PM +0530, Pankaj Chauhan wrote:
>> Introduce support for a generic framework for handling of switching between
>> physical and vhost devices. The vswitch framework introduces the following
>> concept:
>>
>> 1. vswitch_dev: Vswitch device is a logical switch which can have physical 
>> and
>> virtio devices. The devices are operated/used using standard rte_eth API for
>> physical devices and lib_vhost API for vhost devices, PMD API is not used
>> for vhost devices.
>>
>> 2. vswitch_port: Any physical or virtio device that is added to vswitch. The
>> port can have its own tx/rx functions for doing data transfer, which are 
>> exposed
>> to the framework using generic function pointers (vs_port->do_tx/do_rx). 
>> This way
>> the generic code can do tx/rx without understanding the type of device 
>> (Physical or
>> virtio). Similarly each port has its own functions to select tx/rx queues. 
>> The framework
>> provides default tx/rx queue selection functions to the port when port is 
>> added
>> (for both physical and vhost devices). But the framework allows the switch 
>> implementation
>> to override the queue selection functions (vs_port->get_txq/rxq) if required.
>>
>> 3. vswitch_ops: The ops is set of function pointers which are used to do 
>> operations
>> like learning, unlearning, add/delete port, lookup_and_forward. The user of 
>> vswitch
>> framework (vhost/main.[c,h])uses these function pointers to perform above 
>> mentioned
>> operations, thus it remains agnostic of the underlying implementation.
>>
>> Different switching logics can implement their vswitch_device and 
>> vswitch_ops, and
>> register with the framework. This framework makes vhost-switch application 
>> scalable
>> in terms of:
>>
>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
>> 2. Number of ports.
>> 3. Policies of selecting ports for rx and tx.
>>
>> Signed-off-by: Pankaj Chauhan 
>
> Hi,
>
> FYI, my testrobot caught some errors when this patch is applied.
> (And sorry for the late review; hopefully I can make it next week).
>
> --yliu

Hi YLiu,

Thanks for the review. I am sorry it was my mistake in this patchset, 
the header defining few structures and macros used in patch 0001 are 
defined in patch 0003. Because of this 0001 was not individually 
compilable but all three are compliable as set, it was mistake on my 
part , will fix it and will take care of it in further patchsets.

Do you want me to send another version for review, or i can fix it
in the next version i send after review of v2 is complete?

Thanks,
Pankaj
>

[dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management

[Iremonger, Bernard]

Hi Jerin,



> Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF
> management
> 
> On Fri, Aug 26, 2016 at 10:10:18AM +0100, Bernard Iremonger wrote:
> > Add new API functions to configure and manage VF's on a NIC.
> >
> > add rte_eth_dev_vf_ping function.
> > add rte_eth_dev_set_vf_vlan_anti_spoof function.
> > add rte_eth_dev_set_vf_mac_anti_spoof function.
> >
> > Signed-off-by: azelezniak 
> >
> > add rte_eth_dev_set_vf_vlan_strip function.
> > add rte_eth_dev_set_vf_vlan_insert function.
> > add rte_eth_dev_set_loopback function.
> > add rte_eth_dev_set_all_queues_drop function.
> > add rte_eth_dev_set_vf_split_drop_en function add
> > rte_eth_dev_set_vf_mac_addr function.
> 
> Do we really need to expose VF specific functions here?
> It can be generic(PF/VF) function indexed only through port_id.
> (example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, uint8_t on))
> For instance, In Thunderx PMD, We are not exposing a separate port_id for
> PF. We only enumerate 0..N VFs as 0..N ethdev port_id

Our intention with this patch is to control the VF from the PF.

The following librte_ether functions already work in a similar way:

rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf, uint16_t rx_mode, 
uint8_t on)

rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on)

rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on)

int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t tx_rate, 
uint64_t q_msk)

> 
> > increment LIBABIVER to 5.
> >
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  lib/librte_ether/rte_ethdev.c  | 159 +++
> >  lib/librte_ether/rte_ethdev.h  | 223
> +
> >  lib/librte_ether/rte_ether_version.map |   9 ++
> >  3 files changed, 391 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c
> > b/lib/librte_ether/rte_ethdev.c index 1388ea3..2a3d2ae 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -2306,6 +2306,22 @@ rte_eth_dev_default_mac_addr_set(uint8_t
> > port_id, struct ether_addr *addr)  }
> >
> >  int
> > +rte_eth_dev_set_vf_mac_addr(uint8_t port_id, uint16_t vf, struct
> > +ether_addr *addr) {
> > +   struct rte_eth_dev *dev;
> > +
> > +   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > +   if (!is_valid_assigned_ether_addr(addr))
> > +   return -EINVAL;
> > +
> > +   dev = _eth_devices[port_id];
> > +   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_mac_addr, -
> ENOTSUP);
> > +
> > +   return (*dev->dev_ops->set_vf_mac_addr)(dev, vf, addr); }
> > +
> > +int
> >  rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf,
> > uint16_t rx_mode, uint8_t on)
> >  {
> > @@ -2490,6 +2506,149 @@ rte_eth_dev_set_vf_vlan_filter(uint8_t
> port_id, uint16_t vlan_id,
> >vf_mask, vlan_on);
> >  }
> >
> > +int
> > +rte_eth_dev_set_vf_vlan_anti_spoof(uint8_t port_id,
> > +  uint16_t vf, uint8_t on)
> > +{
> > +   struct rte_eth_dev *dev;
> > +
> > +   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > +   dev = _eth_devices[port_id];
> > +   if (vf > 63) {
> 
> PMD may have more than 64 VFs.

Yes, it would be better to check on max_vfs,  the same way as the already 
implemented functions mentioned above.

> 
> 
> > +   RTE_PMD_DEBUG_TRACE("VF VLAN anti spoof:VF %d >
> 63\n", vf);
> > +   return -EINVAL;
> > +   }
> > +
> > +   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops-
> >set_vf_vlan_anti_spoof, -ENOTSUP);
> > +   (*dev->dev_ops->set_vf_vlan_anti_spoof)(dev, vf, on);
> > +   return 0;
> > +}
> > +

Thanks for reviewing.
Regards,

Bernard.

[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework

[Pankaj Chauhan]

On 9/9/2016 2:26 PM, Tan, Jianfeng wrote:
> Hi Pankaj,
>
> Thanks for the massive and great work.

Hi Jianfeng,

Thanks for the review.
>
> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
>> Introduce support for a generic framework for handling of switching
>> between
>> physical and vhost devices. The vswitch framework introduces the
>> following
>> concept:
>>
>> 1. vswitch_dev: Vswitch device is a logical switch which can have
>> physical and
>> virtio devices. The devices are operated/used using standard rte_eth
>> API for
>> physical devices and lib_vhost API for vhost devices, PMD API is not used
>> for vhost devices.
>>
>> 2. vswitch_port: Any physical or virtio device that is added to
>> vswitch. The
>> port can have its own tx/rx functions for doing data transfer, which
>> are exposed
>> to the framework using generic function pointers
>> (vs_port->do_tx/do_rx). This way
>> the generic code can do tx/rx without understanding the type of device
>> (Physical or
>> virtio). Similarly each port has its own functions to select tx/rx
>> queues. The framework
>> provides default tx/rx queue selection functions to the port when port
>> is added
>> (for both physical and vhost devices). But the framework allows the
>> switch implementation
>> to override the queue selection functions (vs_port->get_txq/rxq) if
>> required.
>>
>> 3. vswitch_ops: The ops is set of function pointers which are used to
>> do operations
>> like learning, unlearning, add/delete port, lookup_and_forward. The
>> user of vswitch
>> framework (vhost/main.[c,h])uses these function pointers to perform
>> above mentioned
>> operations, thus it remains agnostic of the underlying implementation.
>>
>> Different switching logics can implement their vswitch_device and
>> vswitch_ops, and
>> register with the framework. This framework makes vhost-switch
>> application scalable
>> in terms of:
>>
>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
>> 2. Number of ports.
>> 3. Policies of selecting ports for rx and tx.
>>
>> Signed-off-by: Pankaj Chauhan 
>
> After this patch set, how's mapping relationship between cores and
> vswitch_dev? Old vhost example does not have the concept of switch, so
> each core is binded with some VDEVs. Now, we still keep original logic?
>
> (a) If yes, provided that phys device could has no direct relationship
> with vdevs in other switching logics, we may need to bind those physical
> devices to cores too? In that case, switch_worker() will receiving pkts
> from all devices (phys or virtual) and dispatch, which looks like:
>
> switch_worker() {
> FOR each port binding to this core {
>  rx(port, pkts[], count);
>  vs_lookup_n_fwd( information_needed );
> }
> }

Since we support only one switch device running at one time. We bind the 
ports of the switchdev to the core. But The switch might have it's own 
logic to bind the port to the core. For example
VMDQ only supports one Physical port, other switch can support more than 
one Physical port. In order to take care of that i have added two ops in 
swithdev_ops:

1. vs_sched_rx_port:

struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum
   vswitch_port_type ptype, uint16_t 
core_id)

2. vs_sched_tx_port:

struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum
   vswitch_port_type ptype, uint16_t
core_id)

The idea of providing these functions is that vhost/main requests the 
underlying switch implementation to schedule a port for rx or Tx, the 
current running core_id is also passed as parameter. So the switch can
take a decision which port to do rx or tx based on core id, and may be 
some other custom policy.

For example VMDQ always returns the one single Physical port in response 
to these functions called from any core. The other switch
can return the ports bound to the cores.

Similarly there are two port operations (vs_port->get_rxq and 
vs_port->get_txq), here also we pass core_id as parameter so that
the underlying switch implementation can schedule the rx or tx queue 
based on the core_id.

The above mentioned ops are used in drain_eth_rx() and 
do_drain_mbuf_table() (main.c) currently, and they leave binding of 
physical port and the queues to the underlying implementation. This
way we can accommodate VMDQ which uses only one physical port and 
rxqueues based on VMDQ, OR any other switch which uses multiple physical 
port and rx/tx queue scheduling based on some other logic.

Please suggest if this way of scheduling ports and tx/rx queues is fine 
or not?
>
> (b) If no, we may bind each core with n switches? If so, switch_worker()
> also need to be reworked to keep receiving pkts from all ports of the
> switch, and dispatch.
>
> switch_worker() {
> FOR each switch binding to this core {
>  FOR each port of switch {
>  rx(port, pkts[], count);
>  vs_lookup_n_fwd( 

[dpdk-dev] imissed in rte_pmd_pcap

[Ferruh Yigit]

Hi Keren,

On 9/12/2016 7:44 AM, Keren Hochman wrote:
> Hello,
> in the dpdk pcap driver, the imissed indicator of rte_eth_stats structure
> is not increasing even when we miss packets since there are no available
> mbufs. I looked at the code and I saw that nothing increase it in the pcap
> driver code ( as opposed to other drivers where it's being promoted)

As you said, it is not implemented, any patch welcome.

> Is there a reason for that?

No specific reason as far as I know.


> Is there other way to follow missed packets
> when using libpcap ?
> Thanks, Keren
> 

[dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Yuanhan,



> Subject: Re: [dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for
> new API's
> 
> On Fri, Aug 26, 2016 at 10:10:20AM +0100, Bernard Iremonger wrote:
> > add test for vf vlan anti spoof
> > add test for vf mac anti spoof
> > add test for vf ping
> > add test for vf vlan strip
> > add test for vf vlan insert
> > add test for tx loopback
> > add test for all queues drop enable bit add test for vf split drop
> > enable bit add test for vf mac address add new API's to the testpmd
> > guide
> >
> > Signed-off-by: Bernard Iremonger 
> 
> Hi,
> 
> FYI, my testrobot caught some errors when this patch is applied.
> (BTW, gcc builds fine)
> 
> --yliu
> 
> ---
> 
> x86_64-native-linuxapp-clang
> 
> /root/dpdk/app/test-pmd/cmdline.c:10629:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:10710:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:10856:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:10938:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:11010:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:11080:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> /root/dpdk/app/test-pmd/cmdline.c:11156:8: error: expression which
> evaluates to zero treated as a null pointer constant of type 'const char *' [-
> Werror,-Wnon-literal-null-conversion]
>  on, UINT8);
>  ^
> /root/dpdk/x86_64-native-linuxapp-
> clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> 'TOKEN_NUM_INITIALIZER'
> numtype,/* type */  \
> ^~~
> 7 errors generated.
> make[5]: *** [cmdline.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> make[4]: *** [test-pmd] Error 2
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [app] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [pre_install] Error 2
> make: *** [install] Error 2
> error: build failed

I am not seeing the above errors when I build with the following commands:

make config T=x86_64-native-linuxapp-clang
make install T=x86_64-native-linuxapp-clang -j

Are you using a different clang config file?

Regards,

Bernard.

[dpdk-dev] [PATCH v5 0/6] vhost: optimize enqueue

[Maxime Coquelin]

On 09/12/2016 03:52 PM, Maxime Coquelin wrote:
> Hi,
>
> On 09/09/2016 05:39 AM, Zhihong Wang wrote:
>> This patch set optimizes the vhost enqueue function.
>>
>> It implements the vhost logic from scratch into a single function
>> designed
>> for high performance and good maintainability, and improves CPU
>> efficiency
>> significantly by optimizing cache access, which means:
>>
>>  *  Higher maximum throughput can be achieved for fast frontends like
>> DPDK
>> virtio pmd.
>>
>>  *  Better scalability can be achieved that each vhost core can support
>> more connections because it takes less cycles to handle each single
>> frontend.
>>
>> This patch set contains:
>>
>>  1. A Windows VM compatibility fix for vhost enqueue in 16.07 release.
>>
>>  2. A baseline patch to rewrite the vhost logic.
>>
>>  3. A series of optimization patches added upon the baseline.
>>
>> The main optimization techniques are:
>>
>>  1. Reorder code to reduce CPU pipeline stall cycles.
>>
>>  2. Batch update the used ring for better efficiency.
>>
>>  3. Prefetch descriptor to hide cache latency.
>>
>>  4. Remove useless volatile attribute to allow compiler optimization.
>>
>> Code reordering and batch used ring update bring most of the performance
>> improvements.
>>
>> In the existing code there're 2 callbacks for vhost enqueue:
>>
>>  *  virtio_dev_merge_rx for mrg_rxbuf turned on cases.
>>
>>  *  virtio_dev_rx for mrg_rxbuf turned off cases.
>>
>> The performance of the existing code is not optimal, especially when the
>> mrg_rxbuf feature turned on. Besides, having 2 callback paths increases
>> maintenance efforts.
>>
>> Also, there's a compatibility issue in the existing code which causes
>> Windows VM to hang when the mrg_rxbuf feature turned on.
>>
>> ---
>> Changes in v5:
>>
>>  1. Rebase to the latest branch.
>>
>>  2. Rename variables to keep consistent in naming style.
>>
>>  3. Small changes like return value adjustment and vertical alignment.
>>
>>  4. Add details in commit log.
> Just tried to apply your series without success.
> Apparently, it is not based directly on master branch,
> as it lacks some SHA-1 information.
>
> Could you rebase it against master please?

Ok, it is in fact based on top of:
git://dpdk.org/next/dpdk-next-virtio master

For v6, if any, could you add this info to the cover letter please?

Thanks,
Maxime

[dpdk-dev] [PATCH v5 0/6] vhost: optimize enqueue

[Maxime Coquelin]

Hi,

On 09/09/2016 05:39 AM, Zhihong Wang wrote:
> This patch set optimizes the vhost enqueue function.
>
> It implements the vhost logic from scratch into a single function designed
> for high performance and good maintainability, and improves CPU efficiency
> significantly by optimizing cache access, which means:
>
>  *  Higher maximum throughput can be achieved for fast frontends like DPDK
> virtio pmd.
>
>  *  Better scalability can be achieved that each vhost core can support
> more connections because it takes less cycles to handle each single
> frontend.
>
> This patch set contains:
>
>  1. A Windows VM compatibility fix for vhost enqueue in 16.07 release.
>
>  2. A baseline patch to rewrite the vhost logic.
>
>  3. A series of optimization patches added upon the baseline.
>
> The main optimization techniques are:
>
>  1. Reorder code to reduce CPU pipeline stall cycles.
>
>  2. Batch update the used ring for better efficiency.
>
>  3. Prefetch descriptor to hide cache latency.
>
>  4. Remove useless volatile attribute to allow compiler optimization.
>
> Code reordering and batch used ring update bring most of the performance
> improvements.
>
> In the existing code there're 2 callbacks for vhost enqueue:
>
>  *  virtio_dev_merge_rx for mrg_rxbuf turned on cases.
>
>  *  virtio_dev_rx for mrg_rxbuf turned off cases.
>
> The performance of the existing code is not optimal, especially when the
> mrg_rxbuf feature turned on. Besides, having 2 callback paths increases
> maintenance efforts.
>
> Also, there's a compatibility issue in the existing code which causes
> Windows VM to hang when the mrg_rxbuf feature turned on.
>
> ---
> Changes in v5:
>
>  1. Rebase to the latest branch.
>
>  2. Rename variables to keep consistent in naming style.
>
>  3. Small changes like return value adjustment and vertical alignment.
>
>  4. Add details in commit log.
Just tried to apply your series without success.
Apparently, it is not based directly on master branch,
as it lacks some SHA-1 information.

Could you rebase it against master please?

Thanks,
Maxime

[dpdk-dev] [PATCH v2] net/bnxt: make driver less verbose

[Ferruh Yigit]

This line printed for every application even if driver is not used at
all. Removing the line to reduce the noise.

Signed-off-by: Ferruh Yigit 
Acked-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 3795fac..d4aa2eb 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1054,9 +1054,9 @@ static struct eth_driver bnxt_rte_pmd = {
.dev_private_size = sizeof(struct bnxt),
 };

-static int bnxt_rte_pmd_init(const char *name, const char *params __rte_unused)
+static int bnxt_rte_pmd_init(const char *name __rte_unused,
+   const char *params __rte_unused)
 {
-   RTE_LOG(INFO, PMD, "bnxt_rte_pmd_init() called for %s\n", name);
rte_eth_driver_register(_rte_pmd);
return 0;
 }
-- 
2.7.4

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Monday, September 12, 2016 10:48 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>Hi Mark/Liu,
>? Thanks to both of you for being so patient with a series 
>of silly errors. I have tried to make it better this time. Also there 
>were some un-used variable in the function which I have removed. Please 
>check the new patch with all your comments incorporated. Also along with the 
>L2_HDR_LEN and L2_CRC_LEN, I have taken in consideration the VLAN_LEN too.
>
>One doubt though,
>"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 
>size is some constrain due to DPDK as the virtio driver in the kernel 
>can support till mtu size of 68 to 65535, where as in DPDK pmd we are trying 
>with 64 to 9728.

Yes, I meant the NIC as controlled by a DPDK PMD (I thought this was implicit, 
given the context of this discussion). I'll be more explicit in future mails 
though.

>
>drivers/net/virtio/virtio_ethdev.c | 19 +++
>1 file changed, 19 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct 
>rte_eth_dev *dev)
>??? PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); }
>
>+#define VLAN_TAG_LEN?? 4??? /* 802.3ac tag (not DMA'd) */
>+
>+static int? virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

One thing on this function: it doesn't actually set any fields, but rather just 
sanitizes 'mtu'.
Maybe this is acceptable, since the calling function (i.e. rte_eth_dev_set_mtu) 
sets rte_eth_dev->data->mtu?
[Dey, Souvik]  Yes , only the sanity check for the mtu is required here and the 
setting of the call back, else the rte_eth_dev_set_mtu() just returns without 
setting the MTU in the rte_eth_dev->data->mtu.

>+{
>+?? struct rte_eth_dev_info dev_info;
>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
>+VLAN_TAG_LEN;
>+?? uint32_t frame_size = mtu + ether_hdr_len;
>+
>+?? virtio_dev_info_get(dev, _info);
>+
>+?? if (mtu < dev_info.min_rx_bufsize || frame_size > 
>+dev_info.max_rx_pktlen) {

It's not clear to me whether 'mtu' in this case should be compared with 
ETHER_MIN_MTU, as per other DPDK drivers, or alternatively whether 'frame_size' 
should be compared with dev_info.min_rx_bufsize.
Any thoughts?
[Dey, Souvik] I am not sure why virtio min_rx_bufsize is less than 
ETHER_MIN_MTU, i think it will be good to have the  compare statement as 
If(frame_size < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) , then 
error. What do you suggest ?

>+?? PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
>+??? ???dev_info.min_rx_bufsize,
As above.

>+?? (dev_info.max_rx_pktlen - 
>+ether_hdr_len));
>+?? return -EINVAL;
>+?? }
>+ ??return 0;
>+}
>@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
>= {
>? ??.allmulticast_enable = virtio_dev_allmulticast_enable,
>??? .allmulticast_disable??? = virtio_dev_allmulticast_disable,
>+?? .mtu_set = virtio_mtu_set,
>??? .dev_infos_get?? = virtio_dev_info_get,
>??? .stats_get?? = virtio_dev_stats_get,
>??? .xstats_get? = virtio_dev_xstats_get,
>
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
>Sent: Friday, September 9, 2016 11:44 AM
>To: Dey, Souvik ; Yuanhan Liu 
>
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio
>
>>
>>Hi Mark,
>>
>>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>>Changed it .
>>Thanks.
>>The MTU here is L3 MTU.? Setting this will help in reducing the 
>>fragmented/multi-segmented packets and also in case we want to reduce 
>>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>>openstack and cloud
>environments.
>>
>>---
>> drivers/net/virtio/virtio_ethdev.c | 12 
>> 1 file changed, 12 insertions(+)
>>
>>diff --git a/drivers/net/virtio/virtio_ethdev.c
>>b/drivers/net/virtio/virtio_ethdev.c
>>index 07d6449..da16ad4 100644
>>--- a/drivers/net/virtio/virtio_ethdev.c
>>+++ b/drivers/net/virtio/virtio_ethdev.c
>>
>>static int virtio_dev_queue_stats_mapping_set(
>> ?? __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 
>>+653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>> ? PMD_INIT_LOG(ERR, "Failed to disable 
>>allmulticast");? }
>>
>>+static int
>>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>>+? struct virtio_hw *hw = 

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Kavanagh, Mark B]

>
>Hi Mark/Liu,
>? Thanks to both of you for being so patient with a series of 
>silly errors. I
>have tried to make it better this time. Also there were some un-used variable 
>in the function
>which I have removed. Please check the new patch with all your comments 
>incorporated. Also
>along with the L2_HDR_LEN and L2_CRC_LEN, I have taken in consideration the 
>VLAN_LEN too.
>
>One doubt though,
>"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 size is 
>some constrain
>due to DPDK as the virtio driver in the kernel can support till mtu size of 68 
>to 65535,
>where as in DPDK pmd we are trying with 64 to 9728.

Yes, I meant the NIC as controlled by a DPDK PMD (I thought this was implicit, 
given the context of this discussion). I'll be more explicit in future mails 
though.

>
>drivers/net/virtio/virtio_ethdev.c | 19 +++
>1 file changed, 19 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>??? PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
>}
>
>+#define VLAN_TAG_LEN?? 4??? /* 802.3ac tag (not DMA'd) */
>+
>+static int? virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

One thing on this function: it doesn't actually set any fields, but rather just 
sanitizes 'mtu'.
Maybe this is acceptable, since the calling function (i.e. rte_eth_dev_set_mtu) 
sets rte_eth_dev->data->mtu?

>+{
>+?? struct rte_eth_dev_info dev_info;
>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_LEN;
>+?? uint32_t frame_size = mtu + ether_hdr_len;
>+
>+?? virtio_dev_info_get(dev, _info);
>+
>+?? if (mtu < dev_info.min_rx_bufsize || frame_size > 
>dev_info.max_rx_pktlen) {

It's not clear to me whether 'mtu' in this case should be compared with 
ETHER_MIN_MTU, as per other DPDK drivers, or alternatively whether 'frame_size' 
should be compared with dev_info.min_rx_bufsize.
Any thoughts?

>+?? PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
>+??? ???dev_info.min_rx_bufsize,
As above.

>+?? (dev_info.max_rx_pktlen - ether_hdr_len));
>+?? return -EINVAL;
>+?? }
>+ ??return 0;
>+}
>@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>? ??.allmulticast_enable = virtio_dev_allmulticast_enable,
>??? .allmulticast_disable??? = virtio_dev_allmulticast_disable,
>+?? .mtu_set = virtio_mtu_set,
>??? .dev_infos_get?? = virtio_dev_info_get,
>??? .stats_get?? = virtio_dev_stats_get,
>??? .xstats_get? = virtio_dev_xstats_get,
>
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
>Sent: Friday, September 9, 2016 11:44 AM
>To: Dey, Souvik ; Yuanhan Liu linux.intel.com>
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio
>
>>
>>Hi Mark,
>>
>>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>>Changed it .
>>Thanks.
>>The MTU here is L3 MTU.? Setting this will help in reducing the
>>fragmented/multi-segmented packets and also in case we want to reduce
>>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>>openstack and cloud
>environments.
>>
>>---
>> drivers/net/virtio/virtio_ethdev.c | 12 
>> 1 file changed, 12 insertions(+)
>>
>>diff --git a/drivers/net/virtio/virtio_ethdev.c
>>b/drivers/net/virtio/virtio_ethdev.c
>>index 07d6449..da16ad4 100644
>>--- a/drivers/net/virtio/virtio_ethdev.c
>>+++ b/drivers/net/virtio/virtio_ethdev.c
>>
>>static int virtio_dev_queue_stats_mapping_set(
>> ?? __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@
>>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>> ? PMD_INIT_LOG(ERR, "Failed to disable 
>> allmulticast");? }
>>
>>+static int
>>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>>+? struct virtio_hw *hw = dev->data->dev_private;
>>+? if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
>
>If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
>overhead before
>performing the comparison above.
>Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
>L2_HDR_LEN +
>9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can accommodate 
>(note that 9728
>is the largest L2 frame size allowed by the NIC, not the largest IP packet 
>size).
>
>>+??? PMD_INIT_LOG(ERR, "Mtu should be between 
>>VIRTIO_MIN_RX_BUFSIZE and
>>VIRTIO_MAX_RX_PKTLEN \n");
>
>Two things on this statement:
>1) in the context of a log message, 

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi All,
Any further comments or updates to be  made in the below patch else I 
will go ahead a submit the v5 for the same.

--
Regards,
Souvik

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dey, Souvik
Sent: Friday, September 9, 2016 2:16 PM
To: Kavanagh, Mark B ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

Hi Mark/Liu,

  Thanks to both of you for being so patient with a series of silly 
errors. I have tried to make it better this time. Also there were some un-used 
variable in the function which I have removed. Please check the new patch with 
all your comments incorporated. Also along with the L2_HDR_LEN and L2_CRC_LEN, 
I have taken in consideration the VLAN_LEN too.



One doubt though,

"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 size is 
some constrain due to DPDK as the virtio driver in the kernel can support till 
mtu size of 68 to 65535, where as in DPDK pmd we are trying with 64 to 9728.



drivers/net/virtio/virtio_ethdev.c | 19 +++

1 file changed, 19 insertions(+)



diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c

index 07d6449..da16ad4 100644

--- a/drivers/net/virtio/virtio_ethdev.c

+++ b/drivers/net/virtio/virtio_ethdev.c

@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

PMD_INIT_LOG(ERR, "Failed to disable allmulticast");

}



+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */

+

+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

+{

+   struct rte_eth_dev_info dev_info;

+   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_LEN;

+   uint32_t frame_size = mtu + ether_hdr_len;

+

+   virtio_dev_info_get(dev, _info);

+

+   if (mtu < dev_info.min_rx_bufsize || frame_size > 
dev_info.max_rx_pktlen) {

+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",

+   dev_info.min_rx_bufsize,

+   (dev_info.max_rx_pktlen - ether_hdr_len));

+   return -EINVAL;

+   }

+   return 0;

+}

@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

.allmulticast_enable = virtio_dev_allmulticast_enable,

.allmulticast_disable= virtio_dev_allmulticast_disable,

+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,

.stats_get   = virtio_dev_stats_get,

.xstats_get  = virtio_dev_xstats_get,





--

Regards,

Souvik



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Friday, September 9, 2016 11:44 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio



>

>Hi Mark,

>

>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>Changed it .

>Thanks.

>The MTU here is L3 MTU.  Setting this will help in reducing the

>fragmented/multi-segmented packets and also in case we want to reduce

>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>openstack and cloud environments.

>

>---

> drivers/net/virtio/virtio_ethdev.c | 12 

> 1 file changed, 12 insertions(+)

>

>diff --git a/drivers/net/virtio/virtio_ethdev.c

>b/drivers/net/virtio/virtio_ethdev.c

>index 07d6449..da16ad4 100644

>--- a/drivers/net/virtio/virtio_ethdev.c

>+++ b/drivers/net/virtio/virtio_ethdev.c

>

>static int virtio_dev_queue_stats_mapping_set(

>__rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@

>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

>   PMD_INIT_LOG(ERR, "Failed to disable 
> allmulticast");  }

>

>+static int

>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {

>+  struct virtio_hw *hw = dev->data->dev_private;

>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {



If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
overhead before performing the comparison above.

Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
L2_HDR_LEN + 9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can 
accommodate (note that 9728 is the largest L2 frame size allowed by the NIC, 
not the largest IP packet size).



>+PMD_INIT_LOG(ERR, "Mtu should be between 
>VIRTIO_MIN_RX_BUFSIZE and

>VIRTIO_MAX_RX_PKTLEN \n");



Two things on this statement:

1) in the context of a log message, VIRTIO_XXX_RX_BUFSIZE most likely means 
very little, and as such is not helpful. I suggest going with the format that I 
included in my earlier mail, which prints the numeric value of the min and max 
rx defines

2)  MTU is an 

[dpdk-dev] [PATCH] doc/guides: add info on how to enable QAT

[Mcnamara, John]

> -Original Message-
> From: Breen, Eoin
> Sent: Tuesday, August 30, 2016 2:27 PM
> To: Jain, Deepak K ; Trahe, Fiona
> ; Griffin, John 
> Cc: dev at dpdk.org; Mcnamara, John ; Breen, Eoin
> 
> Subject: [PATCH] doc/guides: add info on how to enable QAT
> 
> Signed-off-by: Eoin Breen 
> ---
>  doc/guides/cryptodevs/qat.rst | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index cae1958..db03470 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
> @@ -78,6 +78,11 @@ Installation
>  To use the DPDK QAT PMD an SRIOV-enabled QAT kernel driver is required.
> The  VF devices exposed by this driver will be used by QAT PMD.
> 
> +To enable QAT in DPDK you must change the ./config/common_base file.
> +Change the line 'CONFIG_RTE_LIBRTE_PMD_QAT=n' to
> 'CONFIG_RTE_LIBRTE_PMD_QAT=y' to do this.
> +You must then configure and build dpdk, for example using the commands:
> +make T=x86_64-native-linuxapp-gcc config; make
> +

Hi,

>From a documentation point of view the 'make' commands should be on two lines, 
>indented to indicate a code block and prefixed with '::' and a blank line.

The filename and CONFIG items should also be in  backquotes.

John

[dpdk-dev] Run 2 different testpmd from the same machine

[Keren Hochman]

Hi,
I tried to run 2 instances of testpmd from the same machine but received a
message:  Cannot get hugepage information when I tried to run the second
instance. Is there a way to disable hugepages or allow to instances to
access it ? Thanks. keren

[dpdk-dev] [PATCH] app/test: decrease memory requirements for sched

[Olivier Matz]

The sched test consumes 35MB memory. When memory is too fragmented (with
2M hugepages), the test can fail.

To reduce this risk, decrease it to 4.5MB by modifying
n_pipes_per_subport and qsize.

Signed-off-by: Olivier Matz 
---
 app/test/test_sched.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index 63ab084..bd2776d 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -79,8 +79,8 @@ static struct rte_sched_port_params port_param = {
.mtu = 1522,
.frame_overhead = RTE_SCHED_FRAME_OVERHEAD_DEFAULT,
.n_subports_per_port = 1,
-   .n_pipes_per_subport = 4096,
-   .qsize = {64, 64, 64, 64},
+   .n_pipes_per_subport = 1024,
+   .qsize = {32, 32, 32, 32},
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 1,
 };
-- 
2.8.1

[dpdk-dev] [PATCH] app/test: decrease memory requirements for hash

[Olivier Matz]

In hash autotest, the size of tables that should be succesfully created
is 32K entries (256KB), except for the table called "different_name",
which is 1M entries (8MB). When memory is too fragmented (with 2M
hugepages), the test can fail.

To avoid allocation failures due to memory fragmentation, decrease the
size of the table to 32K.

Signed-off-by: Olivier Matz 
---
 app/test/test_hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_hash.c b/app/test/test_hash.c
index 94300e1..2c87efe 100644
--- a/app/test/test_hash.c
+++ b/app/test/test_hash.c
@@ -783,7 +783,7 @@ fbk_hash_unit_test(void)
 */
struct rte_fbk_hash_params different_name = {
.name = "different_name",   /* different 
name */
-   .entries = RTE_FBK_HASH_ENTRIES_MAX,
+   .entries = LOCAL_FBK_HASH_ENTRIES_MAX,
.entries_per_bucket = 4,
.socket_id = 0,
};
-- 
2.8.1

[dpdk-dev] Run 2 different testpmd from the same machine

[Wiles, Keith]

Regards,
Keith

> On Sep 12, 2016, at 6:18 AM, Keren Hochman  
> wrote:
> 
> Hi,
> I tried to run 2 instances of testpmd from the same machine but received a
> message:  Cannot get hugepage information when I tried to run the second
> instance. Is there a way to disable hugepages or allow to instances to
> access it ? Thanks. keren

Running two instances or more DPDK applications you need to make sure the 
resources are split up correctly. You did not supply your command lines being 
used, but I will try to state how it is done.

First memory or huge pages must to allocated to each instance using the 
?socket-mem 128,128 or ?socket-men 128 if you only have one socket in your 
system. Make sure you have enough huge pages allocated in the /etc/sysctl.conf 
file for both instances. In the ?socket-mem 128,128 you are giving 256 huge 
pages to one instance and if the second instance used ?socket-mem 256,256 then 
512 pages, which means you need 256+512 huge pages in the system.

Next the huge page files in the /dev/hugepage directory must have different 
prefixes by using the ?file-prefix option giving different file prefixes for 
each instance. If you have already run DPDK instance once without the option 
please ?sudo rm -fr /dev/hupages/*? to release the current huge pages.

Next you need to make sure you blacklist the port using the -b option on the 
command line of the ports not used by this instance. Each instance needs to 
blacklist the ports not being used. This seems to be the easiest for me, but 
you could look into use the whitelist option as well.

Next make sure you allocate different cores to each instance using the -c or -l 
option, the -l option is a bit easier to read IMO.

Next use the ?proc-type auto in both instances just to be clear. This could be 
optional I think.

I hope this helps. You can also pull down Pktgen and look at the 
pktgen-master.sh and pktgen-slave.sh scripts and modify them for your needs. 
http://dpdk.org/download 

[dpdk-dev] [PATCH 00/13] Add support for secondary queue set in nicvf thunderx driver

[Kamil Rytarowski]

ping


W dniu 26.08.2016 o 18:53, Kamil Rytarowski pisze:
> This series of patches adds support for secondary queue set in nicvf thunderx
> driver
>
> There are two types of VFs:
>   - Primary VF
>   - Secondary VF
>
> Each port consist of a primary VF and n secondary VF(s). Each VF provides 8
> Tx/Rx queues to a port. In case port is configured to use more than 8 queues,
> then it requires one (or more) secondary VF. Each secondary VF adds additional
> 8 queues to the queue set.
>
> During PMD driver initialization, the primary VF's are enumerated by checking 
> the
> specific flag (see READY message). They are at the beginning of  VF list (the 
> remain
> ones are secondary VF's).
>
> The primary VFs are used as master queue sets. Secondary VFs provide
> additional queue sets for primary ones. If a port is configured for more then
> 8 queues then it will request for additional queues from secondary VFs.
>
> Secondary VFs cannot be shared between primary VFs.
>
> Primary VFs are present on the tail of the 'Network devices using kernel
> driver' list, secondary VFs are on the remaining tail of the list.
>
> The VNIC driver in the multiqueue setup works differently than other drivers
> like `ixgbe`. We need to bind separately each specific queue set device with
> the ``tools/dpdk-devbind.py`` utility.
>
> Depending on the hardware used, the kernel driver sets a threshold ``vf_id``.
> VFs that try to attach with an id below or equal to this boundary are
> considered primary VFs. VFs that try to attach with an id above this boundary
> are considered secondary VFs.
>
> This patchset also contains other cleanups and improvements like fixing
> erroneous checksum calculation and preparing the thunderx driver for the multi
> queue set feature support.
>
>
> These changes base on the following pending patches:
>
> [dpdk-dev,1/3] net/thunderx: remove generic passx references from the driver
> http://dpdk.org/dev/patchwork/patch/14963/
>
> [dpdk-dev,2/3] net/thunderx: introduce cqe_rx2 HW capability flag
> http://dpdk.org/dev/patchwork/patch/14964/
>
> [dpdk-dev,3/3] net/thunderx: add 81xx SoC support
> http://dpdk.org/dev/patchwork/patch/14965/
>
> Kamil Rytarowski (13):
>net/thunderx: cleanup the driver before adding new features
>net/thunderx: correct transmit checksum handling
>net/thunderx/base: add family of functions to store qsets
>net/thunderx/base: add secondary queue set support
>net/thunderx: add family of functions to store DPDK qsets
>net/thunderx: add secondary queue set in interrupt functions
>net/thunderx: fix multiprocess support in stats
>net/thunderx: add helper utils for secondary qset support
>net/thunderx: add secondary qset support in dev stop/close
>net/thunderx: add secondary qset support in device start
>net/thunderx: add secondary qset support in device configure
>net/thunderx: add final bits for secondary queue support
>net/thunderx: document secondary queue set support
>
>   doc/guides/nics/thunderx.rst  | 114 -
>   drivers/net/thunderx/Makefile |   2 +
>   drivers/net/thunderx/base/nicvf_bsvf.c|  72 +++
>   drivers/net/thunderx/base/nicvf_bsvf.h|  76 +++
>   drivers/net/thunderx/base/nicvf_hw.c  |  10 +-
>   drivers/net/thunderx/base/nicvf_hw.h  |   6 +-
>   drivers/net/thunderx/base/nicvf_hw_defs.h |   1 +
>   drivers/net/thunderx/base/nicvf_mbox.c|  34 +-
>   drivers/net/thunderx/base/nicvf_mbox.h|  21 +-
>   drivers/net/thunderx/nicvf_ethdev.c   | 753 
> +-
>   drivers/net/thunderx/nicvf_ethdev.h   |  39 ++
>   drivers/net/thunderx/nicvf_rxtx.c |  14 +-
>   drivers/net/thunderx/nicvf_struct.h   |   6 +-
>   drivers/net/thunderx/nicvf_svf.c  |  78 
>   drivers/net/thunderx/nicvf_svf.h  |  66 +++
>   15 files changed, 1046 insertions(+), 246 deletions(-)
>   create mode 100644 drivers/net/thunderx/base/nicvf_bsvf.c
>   create mode 100644 drivers/net/thunderx/base/nicvf_bsvf.h
>   create mode 100644 drivers/net/thunderx/nicvf_svf.c
>   create mode 100644 drivers/net/thunderx/nicvf_svf.h
>

[dpdk-dev] [PATCH] app/test: fix failing packet-framework table unit-tests

[Jasvinder Singh]

The pipeline object is not freed when a particular test-case of the unit-test
finishes. Using rte_pipeline_free() before returning the outcome for each
test-case fixes the issue.

Fixes: 5205954791cb ("app/test: packet framework unit tests")

Signed-off-by: Jasvinder Singh 
---
 app/test/test_table_combined.c | 45 +++---
 1 file changed, 34 insertions(+), 11 deletions(-)

diff --git a/app/test/test_table_combined.c b/app/test/test_table_combined.c
index acb4f4d..8724afa 100644
--- a/app/test/test_table_combined.c
+++ b/app/test/test_table_combined.c
@@ -110,8 +110,10 @@ test_table_type(struct rte_table_ops *table_ops, void 
*table_args,
};

if (rte_pipeline_port_in_create(pipeline, _in_params,
-   _in_id) != 0)
+   _in_id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_PORT_CONFIG;
+   }

/* Create table */
struct rte_pipeline_table_params table_params = {
@@ -123,8 +125,11 @@ test_table_type(struct rte_table_ops *table_ops, void 
*table_args,
.action_data_size = 0,
};

-   if (rte_pipeline_table_create(pipeline, _params, _id) != 0)
+   if (rte_pipeline_table_create(pipeline, _params,
+   _id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_TABLE_CONFIG;
+   }

/* Create output ports */
ring_params_tx.ring = RING_TX;
@@ -136,14 +141,18 @@ test_table_type(struct rte_table_ops *table_ops, void 
*table_args,
};

if (rte_pipeline_port_out_create(pipeline, _out_params,
-   _out_id) != 0)
+   _out_id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_PORT_CONFIG;
+   }

ring_params_tx.ring = RING_TX_2;

if (rte_pipeline_port_out_create(pipeline, _out_params,
-   _out_2_id) != 0)
+   _out_2_id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_PORT_CONFIG;
+   }

/* Add entry to the table */
struct rte_pipeline_table_entry default_entry = {
@@ -161,24 +170,34 @@ test_table_type(struct rte_table_ops *table_ops, void 
*table_args,
int key_found;

if (rte_pipeline_table_default_entry_add(pipeline, table_id,
-   _entry, _entry_ptr) != 0)
+   _entry, _entry_ptr) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_DEFAULT_ENTRY_ADD;
+   }

if (rte_pipeline_table_entry_add(pipeline, table_id,
key ? key : _entry, _entry, _found,
-   _ptr) != 0)
+   _ptr) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_ENTRY_ADD;
+   }

/* Create connections and check consistency */
if (rte_pipeline_port_in_connect_to_table(pipeline, ring_in_id,
-   table_id) != 0)
+   table_id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_CONNECT;
+   }

-   if (rte_pipeline_port_in_enable(pipeline, ring_in_id) != 0)
+   if (rte_pipeline_port_in_enable(pipeline, ring_in_id) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_PORT_ENABLE;
+   }

-   if (rte_pipeline_check(pipeline) != 0)
+   if (rte_pipeline_check(pipeline) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_CONSISTENCY;
+   }



@@ -234,13 +253,17 @@ test_table_type(struct rte_table_ops *table_ops, void 
*table_args,
table_entry.table_id = ring_out_2_id;

if (rte_pipeline_table_default_entry_add(pipeline, table_id,
-   _entry, _entry_ptr) != 0)
+   _entry, _entry_ptr) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_ENTRY_ADD;
+   }

if (rte_pipeline_table_entry_add(pipeline, table_id,
key ? key : _entry, _entry, _found,
-   _ptr) != 0)
+   _ptr) != 0) {
+   rte_pipeline_free(pipeline);
return -CHECK_TABLE_ENTRY_ADD;
+   }

/* Check that traffic destination has changed */
if (table_packets->n_hit_packets) {
-- 
2.5.5

[dpdk-dev] [PATCH v9 07/25] driver: init/uninit common wrappers for PCI drivers

[Thomas Monjalon]

2016-09-12 09:16, David Marchand:
> On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain  
> wrote:
> > crypto and ethdev drivers aligned to PCI probe/remove. Existing handlers for
> > init/uninit can be easily reused for this.
> 
> I would keep in the commit log a mention on the 1 - 1 association
> between the ethdev/crypto device and the pci device.
> 
> Besides, I kind of remember a suggestion to rename init as probe and
> uninit as remove (Thomas ?).

Yes, here:
http://dpdk.org/ml/archives/dev/2016-July/044086.html

> But this can go later in the series.

[dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure

[Thomas Monjalon]

2016-09-12 08:42, Tan, Jianfeng:
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > FYI, my testrobot caught some errors when this patch is applied.
> 
> It's because this patch set has dependency on a previous patch set, which 
> seems a difficult scenario to handle. There's no standard to state the 
> dependency, right?

No there is no standard to state the dependency.
We need one. Actually, there are 3 kinds of dependencies:
- a well know dependency when sending a patch
- implicit dependency on the HEAD
(can fail if a conflicting patch is pushed)
- dependency on a specific tree (next-*)

I suggest using:
Depends-on: pw | 
Examples:
Depends-on: pw 33000
Depends-on: master 3643b0f
Depends-on: next-net f33e00

It won't work well when a patch depends on a pending patch series
because the cover letter has no patchwork identifier.
It will be solved with the next version of patchwork (in few months).
In the meantime, we can point to the first patch of the series.

Comments/ideas?

[dpdk-dev] [PATCH 1/2] net/i40e: add func to check link speed

[Yuanhan Liu]

On Mon, Sep 12, 2016 at 03:43:53AM +0800, Zhang Qi wrote:
> Add a help function to check link speed by device ID.
> Replace macro "i40e_is_40G_device" with the new function.
> 
> Signed-off-by: Zhang Qi 

Hi,

FYI, my testrobot caught some warnings whlie applying this patch

--yliu

---
Applying: net/i40e: add func to check link speed
.git/rebase-apply/patch:42: trailing whitespace.

.git/rebase-apply/patch:62: trailing whitespace.

.git/rebase-apply/patch:127: trailing whitespace.
}
warning: 3 lines add whitespace errors.

[dpdk-dev] [PATCH 1/5] eal: make enum rte_kernel_driver non-PCI specific

[Shreyansh Jain]

Hi,

On Sunday 11 September 2016 05:45 PM, Yuanhan Liu wrote:
> On Thu, Sep 01, 2016 at 10:11:51AM +0530, Shreyansh Jain wrote:
>> From: Jan Viktorin 
>>
>> From: Jan Viktorin 
>>
>> Signed-off-by: Jan Viktorin 
>> Signed-off-by: Shreyansh Jain 
>
> Hi,
>
> FYI, my testrobot caught some errors when this patch is applied.
>
> --yliu
>
> ---
> i686-native-linuxapp-gcc: config-all-yes
> 
> In file included from lib/librte_eal/linuxapp/eal/eal_pci.c:38:0:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> In file included from lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c:52:0:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> In file included from lib/librte_eal/common/eal_private.h:38:0,
>  from lib/librte_eal/linuxapp/eal/eal_thread.c:55:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> make[7]: *** [eal_thread.o] Error 1
> make[7]: *** Waiting for unfinished jobs
> In file included from lib/librte_eal/linuxapp/eal/eal.c:72:0:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> In file included from lib/librte_eal/common/eal_private.h:38:0,
>  from lib/librte_eal/linuxapp/eal/eal_memory.c:97:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> In file included from lib/librte_eal/common/eal_private.h:38:0,
>  from lib/librte_eal/linuxapp/eal/eal_log.c:50:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> make[7]: *** [eal_log.o] Error 1
> make[7]: *** [eal_vfio_mp_sync.o] Error 1
> In file included from lib/librte_eal/common/eal_private.h:38:0,
>  from lib/librte_eal/linuxapp/eal/eal_vfio.c:45:
> i686-native-linuxapp-gcc/include/rte_pci.h:157:25: error: field 'kdrv' has 
> incomplete type
>   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
>  ^
> make[7]: *** [eal.o] Error 1
> make[7]: *** [eal_memory.o] Error 1
> make[7]: *** [eal_vfio.o] Error 1
> lib/librte_eal/linuxapp/eal/eal_pci.c: In function 'rte_eal_pci_map_device':
> lib/librte_eal/linuxapp/eal/eal_pci.c:133:7: error: 'RTE_KDRV_VFIO' 
> undeclared (first use in this function)
>   case RTE_KDRV_VFIO:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c:133:7: note: each undeclared identifier 
> is reported only once for each function it appears in
> lib/librte_eal/linuxapp/eal/eal_pci.c:139:7: error: 'RTE_KDRV_IGB_UIO' 
> undeclared (first use in this function)
>   case RTE_KDRV_IGB_UIO:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c:140:7: error: 'RTE_KDRV_UIO_GENERIC' 
> undeclared (first use in this function)
>   case RTE_KDRV_UIO_GENERIC:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c: In function 'rte_eal_pci_unmap_device':
> lib/librte_eal/linuxapp/eal/eal_pci.c:160:7: error: 'RTE_KDRV_VFIO' 
> undeclared (first use in this function)
>   case RTE_KDRV_VFIO:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c:163:7: error: 'RTE_KDRV_IGB_UIO' 
> undeclared (first use in this function)
>   case RTE_KDRV_IGB_UIO:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c:164:7: error: 'RTE_KDRV_UIO_GENERIC' 
> undeclared (first use in this function)
>   case RTE_KDRV_UIO_GENERIC:
>^
> lib/librte_eal/linuxapp/eal/eal_pci.c: In function 'pci_scan_one':
> lib/librte_eal/linuxapp/eal/eal_pci.c:381:16: error: 'RTE_KDRV_VFIO' 
> undeclared (first use in this function)
> dev->kdrv = RTE_KDRV_VFIO;
> ^
> lib/librte_eal/linuxapp/eal/eal_pci.c:383:16: error: 'RTE_KDRV_IGB_UIO' 
> undeclared (first use in this function)
> dev->kdrv = RTE_KDRV_IGB_UIO;
> ^
> lib/librte_eal/linuxapp/eal/eal_pci.c:385:16: error: 'RTE_KDRV_UIO_GENERIC' 
> undeclared (first use in this function)
> dev->kdrv = RTE_KDRV_UIO_GENERIC;
> ^
> lib/librte_eal/linuxapp/eal/eal_pci.c:387:16: error: 'RTE_KDRV_UNKNOWN' 
> undeclared (first use in this function)
> dev->kdrv = RTE_KDRV_UNKNOWN;
> ^
> lib/librte_eal/linuxapp/eal/eal_pci.c:389:15: error: 'RTE_KDRV_NONE' 
> undeclared (first use in this function)
>dev->kdrv = 

[dpdk-dev] [PATCH v9 17/25] drivers: convert PMD_VDEV drivers to use rte_vdev_driver

[Shreyansh Jain]

Hi ,

On Sunday 11 September 2016 05:25 PM, Yuanhan Liu wrote:
> On Wed, Sep 07, 2016 at 07:38:09PM +0530, Shreyansh Jain wrote:
>> All PMD_VDEV drivers can now use rte_vdev_driver instead of the
>> rte_driver (which is embedded in the rte_vdev_driver).
>>
>> Signed-off-by: Jan Viktorin 
>> Signed-off-by: Shreyansh Jain 
>
> Hi,
>
> FYI, my testrobot caught some errors when this patch is applied.
>
>   --yliu
>
> i686-native-linuxapp-gcc: config-all-yes-shared
> ===
> rte_eth_af_packet.o: In function `vdrvinitfn_pmd_af_packet_drv':
> rte_eth_af_packet.c:(.text.startup+0x23): undefined reference to 
> `rte_eal_vdrv_register'
> collect2: error: ld returned 1 exit status
> make[6]: *** [librte_pmd_af_packet.so.1.1] Error 1
> make[5]: *** [af_packet] Error 2
> make[5]: *** Waiting for unfinished jobs
> rte_eth_bond_pmd.o: In function `vdrvinitfn_bond_drv':
> rte_eth_bond_pmd.c:(.text.startup+0x23): undefined reference to 
> `rte_eal_vdrv_register'
> collect2: error: ld returned 1 exit status
> make[6]: *** [librte_pmd_bond.so.1.1] Error 1
> make[5]: *** [bonding] Error 2
> make[4]: *** [net] Error 2
> make[3]: *** [drivers] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [pre_install] Error 2
> make: *** [install] Error 2
> error: build failed
>

Thanks!
I think this is similar to what Ferruh has commented in [1]. I missed 
adding these functions to the map file in the 16th patch which is why 
shared library is failing. I have noted that for change in v10 as and 
when that is ready.

[1] http://dpdk.org/ml/archives/dev/2016-September/046399.html

--
Shreyansh

[dpdk-dev] imissed in rte_pmd_pcap

[Keren Hochman]

Hello,
in the dpdk pcap driver, the imissed indicator of rte_eth_stats structure
is not increasing even when we miss packets since there are no available
mbufs. I looked at the code and I saw that nothing increase it in the pcap
driver code ( as opposed to other drivers where it's being promoted)
Is there a reason for that? Is there other way to follow missed packets
when using libpcap ?
Thanks, Keren

[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization

[David Marchand]

Hello Shreyansh,

On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain  
wrote:

>  This patch is part of larger aim to:
>
>  + 
>  eth_driver (PMD)|-> rte_driver
>  crypto_driver (PMD) |   ^
>  |   |
>  +   | 
> /
>+---/+
>| rte_pci_driver |
>| rte_vdev_driver|
>| rte_soc_driver |
>| rte_xxx_driver |
>
>  Where PMD devices (rte_eth_dev, rte_cryptodev_dev) are connected to their
>  drivers rather than explicitly inheriting type specific driver (PCI, etc).
>
>
> About the Patches:
> ==
>
> There are a large number of patches for this - primarily because the changes
> are quite varied and keeping them logically separate yet compilable is
> important. Most of the patches are small and those which are large touch the
> drivers (PMDs) to accommodate the structure changes:
>
>  - Patches 0001~0003 are for introducing the container_of function (so that
>rte_device can be obtained from rte_pci_device, for example), and
>removing unused code.
>  - Patches 0004~0007 just perform the ground work for enabling change from
>rte_driver/eth_driver based PMDs to rte_xxx_driver based PMDs
>  - In patch 0008, all the pdev PMDs are changed to support rte_pci_driver (
>including cryptodev, which is eventually generalized with PCI)
>  - Patch 0009~0010 merge the crypto and pci functions for registration and
>naming.
>  - Patches 0011~0014 deal with hotplugging - hotplug no more invokes scan of
>complete bus and has been generalized into EAl from ethdev.
>  - Patches 0015 introduces vdev init/uninit into separate C units and
>enables its compilation. Patch 0016~0017 build on it and remove the
>remaining legacy support for vdev/pdev distinctions.
>  - Patches 0018~0022 enable the vdev drivers to register using the
>DRIVER_REGISTER_* operations, and remove their rte_driver->init()
>  - Patch 0023 enables the rte_driver registration into a common driver
>linked list.
>  - Patches 0024~0025 introduce the rte_device, a generalization of
>rte_xxx_device, and associated operation of creating rte_device linked
>list. It also enables the drivers to use rte_device.name/numa_node
>members rather than rte_xxx_device specific members.
>
> Notes:
> ==
>
> * Some sign-off were already provided by Jan on the original v5; But, as a
>   large number of merges have been made, I am leaving those out just in case
>   it is not sync with initial understanding.
>
> * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
>   removed [7].
>
> Future Work/Pending:
> ===
>  - Presently eth_driver, rte_eth_dev are not aligned to the rte_driver/
>rte_device model. eth_driver still is a PCI specific entity. This
>has been highlighted by comments from Ferruh in [9].
>  - cryptodev driver too still remains to be normalized over the rte_driver
>model
>  - Some variables, like drv_name (as highlighted by Ferruh), are getting
>duplicated across rte_xxx_driver/device and rte_driver/device.

Overall, we are still missing some parts :
- in my initial proposition, the rte_driver would embed the
probe/remove (previsouly init/uninit) functions that would take
rte_device object as arguments (and maybe we should get rid of the
double lists, I am not yet convinced it is easy).
- the pmdinfo stuff is broken and could be implemented for vdev, I did
a quick patch that replaces the "PMD_REGISTER_DRIVER(.*)" regexp as
"DRIVER_REGISTER_.*(.*)" then I added a DRIVER_EXPORT_NAME(nm,
__COUNTER__) in the vdev register macro, it looks to work fine.
pmdinfo is a bit too pci but I think we can go with this.
- the names should go to rte_device/rte_driver objects ?



-- 
David Marchand

[dpdk-dev] [PATCH] net/i40e: fix outer VLAN bitmask for input set

[Wu, Jingjing]

> -Original Message-
> From: Xing, Beilei
> Sent: Monday, September 12, 2016 5:27 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org; Xing, Beilei
> Subject: [PATCH] net/i40e: fix outer VLAN bitmask for input set
> 
> This patch changes bitmask of outer VLAN tag in L2 header to support RSS
> and flow director for QinQ.
> 
> Fixes: 4072d503aaa5 ("i40e: fix VLAN bitmasks for input set")
>
HI, Beilei

I think this fix is based on " net/i40e: fix parsing QinQ packets type issue"
 http://dpdk.org/dev/patchwork/patch/15267/. 

Could you merge them to a one patch.

[dpdk-dev] [PATCH v9 13/25] ethdev: convert to eal hotplug

[David Marchand]

On Wed, Sep 7, 2016 at 4:08 PM, Shreyansh Jain  
wrote:

[snip]

> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index fdeac86..86c9d1a 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c

[snip]

> +   ret = rte_eal_dev_attach(name, args);
> +   if (ret < 0)
> +   goto err;
> +
> +   /* no point looking at eth_dev_last_created_port if no port exists */
> +   if (!nb_ports) {
> +   RTE_LOG(ERR, EAL, "No ports founds for device (%s)\n", name);

No port found ?


-- 
David Marchand

[dpdk-dev] [PATCH v9 08/25] drivers: convert all pdev drivers as pci drivers

[David Marchand]

On Wed, Sep 7, 2016 at 4:08 PM, Shreyansh Jain  
wrote:
> Simplify crypto and ethdev pci drivers init by using newly introduced
> init macros and helpers.
> Those drivers then don't need to register as "rte_driver"s anymore.
>
> Exceptions:
> - virtio and mlx* use RTE_INIT directly as they have custom initialization
>   steps.

Afaics, we are missing some DRIVER_EXPORT_NAME for those.

> - VDEV devices are not modified - they continue to use PMD_REGISTER_DRIVER.
>
> Signed-off-by: David Marchand 
> Signed-off-by: Shreyansh Jain 


-- 
David Marchand

[dpdk-dev] [PATCH v9 07/25] driver: init/uninit common wrappers for PCI drivers

[David Marchand]

On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain  
wrote:
> crypto and ethdev drivers aligned to PCI probe/remove. Existing handlers for
> init/uninit can be easily reused for this.

I would keep in the commit log a mention on the 1 - 1 association
between the ethdev/crypto device and the pci device.

Besides, I kind of remember a suggestion to rename init as probe and
uninit as remove (Thomas ?).
But this can go later in the series.


-- 
David Marchand

[dpdk-dev] [PATCH v9 06/25] eal: introduce init macros

[David Marchand]

On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain  
wrote:
> diff --git a/lib/librte_eal/common/include/rte_pci.h 
> b/lib/librte_eal/common/include/rte_pci.h
> index fa74962..cf673e4 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -470,6 +470,16 @@ void rte_eal_pci_dump(FILE *f);
>   */
>  void rte_eal_pci_register(struct rte_pci_driver *driver);
>
> +/** Helper for PCI device registeration from driver (eth, crypto) instance */

Typo: registration

> +#define DRIVER_REGISTER_PCI(nm, pci_drv) \
> +RTE_INIT(pciinitfn_ ##nm); \
> +static void pciinitfn_ ##nm(void) \
> +{ \
> +   (pci_drv).name = RTE_STR(nm);\
> +   rte_eal_pci_register(_drv); \
> +}\
> +DRIVER_EXPORT_NAME(nm, __COUNTER__)

Checkpatch complains about a missing space.


-- 
David Marchand

[dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure

[Tan, Jianfeng]

Hi Yuanhan,

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Sunday, September 11, 2016 8:09 PM
> To: Tan, Jianfeng
> Cc: dev at dpdk.org; Ananyev, Konstantin; Wu, Jingjing; Kavanagh, Mark B;
> Thomas Monjalon
> Subject: Re: [dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on
> VXLAN failure
> 
> On Thu, Aug 04, 2016 at 07:58:48AM +, Jianfeng Tan wrote:
> > Based on previous fix of offload on VXLAN using i40e, applications
> > need to set proper tunneling type on ol_flags so that i40e driver
> > can pass it to NIC.
> >
> > Fixes: a50245ede72a ("examples/tep_term: initialize VXLAN sample")
> >
> > Signed-off-by: Jianfeng Tan 
> > ---
> >  examples/tep_termination/vxlan.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/examples/tep_termination/vxlan.c
> b/examples/tep_termination/vxlan.c
> > index 5ee1f95..4bad33d 100644
> > --- a/examples/tep_termination/vxlan.c
> > +++ b/examples/tep_termination/vxlan.c
> > @@ -237,6 +237,8 @@ encapsulation(struct rte_mbuf *m, uint8_t
> queue_id)
> > m->outer_l2_len = sizeof(struct ether_hdr);
> > m->outer_l3_len = sizeof(struct ipv4_hdr);
> >
> > +   ol_flags |= PKT_TX_TUNNEL_VXLAN;
> > +
> 
> Hi,
> 
> FYI, my testrobot caught some errors when this patch is applied.

It's because this patch set has dependency on a previous patch set, which seems 
a difficult scenario to handle. There's no standard to state the dependency, 
right?

Thanks,
Jianfeng

> 
>   --yliu
> 
> ---
> x86_64-native-linuxapp-clang: config-all-yes
> 
> /root/dpdk/examples/tep_termination/vxlan.c:240:14: error: use of
> undeclared identifier 'PKT_TX_TUNNEL_VXLAN'
> ol_flags |= PKT_TX_TUNNEL_VXLAN;
> ^
> 1 error generated.
> make[1]: *** [vxlan.o] Error 1
> make: *** [all] Error 2
> error: build examples/tep_termination failed
> error: build failed
> 
> ...

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Neil Horman]

On Sat, Sep 10, 2016 at 11:31:04AM -0700, Stephen Hemminger wrote:
> I think that if the driver is just a shim for proprietary code, then the
> vendor should just maintain it out of tree. 6wind and windriver already do
> this.
Agreed, this was my previous comment.  Someone probably wants this driver, but I
dont' want to maintain a shim.  Until its ready to be all open source, just
maintain it out of tree

Neil

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Neil Horman]

On Sat, Sep 10, 2016 at 07:58:38AM +, Finn Christensen wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: 9. september 2016 15:51
> > To: Finn Christensen 
> > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com;
> > stephen at networkplumber.org
> > Subject: Re: [PATCH v3] ntnic: add PMD driver
> >
> > On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote:
> > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK.
> > >
> > > This patch adds support for Napatech NICs to DPDK. This is the
> > > initial implementation.
> > >
> > > Signed-off-by: Finn Christensen 
> > > ---
> > > v3:
> > >   * Removed the need for binary libraries on build
> > > v2:
> > >   * Added information how to build the PMD without NIC
> > > Board Support Package
> > >   * Fixed some formatting issues
> > So, this is a step in the right direction, but I think its solving the wrong
> > problem.  If you have a dependency on an external library, thats ok, and
> > accessing it via dlopen makes it possible to build the library without 
> > having
> > that library present, but it not really in keeping with the spirit of what I
> > meant.  This driver is still effectively dependent on a binary blob that we
> > have
> > no visibility into.  The better solution is releasing the source for the 
> > ntnic
> > and ntos libraries.  The license file in the referenced git tree indicates 
> > its
> > BSD licensed, so I don't think there should be a problem in doing that.
> >
> > Neil
> >
> No, unfortunately the ntapi is not BSD licensed, only the header files that
> you can freely download are.
> We are building this NT NIC by using parts or our technology from our
> capture adapters and that is using closed source software.
> 
That seems to be different than what your github tree indicates, since the
binaries were included in a tree with the BSD license in it.  Though I see
you've removed those now:
https://github.com/napa-tech/ntapi/commits/master

> We are new to opensource and we want to go that way, but we haven't
> yet a complete stand-alone driver ready that we can put into the DPDK
> PMD to have a complete self contained and open sourced DPDK PMD, that
> only needs the actual HW NIC plugged in to run.
> Therefore this version is implemented as a virtual device, exactly like the
> PCAP PMD driver is, and it runs on top of a driver that follows the NIC 
> itself.

A stand alone driver that doesn't require additional proprietary software is
really the goal, yes, but its also the minimum requirement.  Providing a driver
that can only be used with additional proprietary sofware doesn't help anyone,
as it just means more maintenence for other developers, while not getting the
ability to work with new hardware in any meaningful way.

Thats not to say that the driver you are providing isn't useful, some end user
might find it very useful.  But its not fair to the developers working on the
DPDK, to ask them to provide maintenence on your driver, when they can't use it
without aquiescing to whatever proprietary license you may have. 

Given the situation you're in, I think the right solution is for you to maintain
this driver out of tree, until such time as it can be used without any
proprietary software, at which point it can be integrated.
> 
> In regards to the DPDK functionality we do not see that anything is missing.
> I cannot either see where we should add source code, because it is not part
> of the DPDK package and it should not be either.
> 
Whats missing is the ability to use your driver without having to agree to
whatever demands your closed source license impose upon other developers.  When
you contribute to an open source project there an implied agreement between the
development community and the contributor

1) When other developers make changes to the core project, your driver will get
updated to comply with any needed corresponding changes

2) When other developers find a bug that affects your NIC (via testing or visual
inspection), they'll fix it

3) Other community developers get the ability to modify your driver to create
new features or other enhancements

By accepting this, you get the advantage of 1 and 2, but prevent any ability for
other developers to take advantage of (3), because you're code is behind some
additional license that renders the driver useless unless you agree to it.

> One of the things I really liked about the DPDK open source project is that it
> uses BSD licensing not GPL. Therefore, I must admit, we  completely failed
> to see that the "spirit" of the DPDK community is not really BSD. Our view
> of this community was that the main driving force of it was to be able to
> make DPDK run on everything anywhere effectively, in a global contributing
> community, without  any legally constrains prohibiting us to do so.
> 
This is a pretty telling comment.  The BSD license basically says, keep the
license in place, and do what you want 

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Finn Christensen]

Yes, this we can do without asking you guys, and we already do so. But that is 
not what this ntnic PMD is about.
We have built a NT NIC out of our existing accelerator products. This NIC is 
built using an FPGA and is targeted towards NFV acceleration in virtualized 
environments. Now, we have seen good acceleration results in our tests by using 
DPDK (with small additions to DPDK). What we want to do is to make this part of 
open source DPDK and in general run this project in an open source spirit.
We want to make further RFCs to the DPDK community about extensions to the DPDK 
that can accelerate packet processing, and this ntnic PMD is the first step in 
our participation/contribution into the DPDK project.
Furthermore, we do not think in proprietary code with this project, and no 
further libraries or other external closed source dependencies will be added in 
upcoming contributions from our side (at least we have no plan in doing so).

Finn

From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: 10. september 2016 20:31
To: Thomas Monjalon 
Cc: dev at dpdk.org; Finn Christensen ; Neil Horman 

Subject: Re: [PATCH v3] ntnic: add PMD driver


I think that if the driver is just a shim for proprietary code, then the vendor 
should just maintain it out of tree. 6wind and windriver already do this.

Disclaimer: This email and any files transmitted with it may contain 
confidential information intended for the addressee(s) only. The information is 
not to be surrendered or copied to unauthorized persons. If you have received 
this communication in error, please notify the sender immediately and delete 
this e-mail from your system.

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Finn Christensen]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: 10. september 2016 10:20
> To: Finn Christensen 
> Cc: Neil Horman ; dev at dpdk.org;
> stephen at networkplumber.org
> Subject: Re: [PATCH v3] ntnic: add PMD driver
>
> 2016-09-10 07:58, Finn Christensen:
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote:
> > > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK.
> > > >
> > > > This patch adds support for Napatech NICs to DPDK. This is the
> > > > initial implementation.
> > > >
> > > > Signed-off-by: Finn Christensen 
> > > > ---
> > > > v3:
> > > >   * Removed the need for binary libraries on build
> > > > v2:
> > > >   * Added information how to build the PMD without NIC
> > > > Board Support Package
> > > >   * Fixed some formatting issues
> > >
> > > So, this is a step in the right direction, but I think its solving
> > > the wrong problem.  If you have a dependency on an external library,
> > > thats ok, and accessing it via dlopen makes it possible to build the
> > > library without having that library present, but it not really in
> > > keeping with the spirit of what I meant.  This driver is still
> > > effectively dependent on a binary blob that we have no visibility
> > > into.  The better solution is releasing the source for the ntnic and
> > > ntos libraries.  The license file in the referenced git tree
> > > indicates its BSD licensed, so I don't think there should be a problem in
> doing that.
> > >
> > > Neil
> > >
> > No, unfortunately the ntapi is not BSD licensed, only the header files
> > that you can freely download are.
> > We are building this NT NIC by using parts or our technology from our
> > capture adapters and that is using closed source software.
> >
> > We are new to opensource and we want to go that way, but we haven't
> > yet a complete stand-alone driver ready that we can put into the DPDK
> > PMD to have a complete self contained and open sourced DPDK PMD, that
> > only needs the actual HW NIC plugged in to run.
> > Therefore this version is implemented as a virtual device, exactly
> > like the PCAP PMD driver is, and it runs on top of a driver that follows the
> NIC itself.
> >
> > In regards to the DPDK functionality we do not see that anything is missing.
> > I cannot either see where we should add source code, because it is not
> > part of the DPDK package and it should not be either.
> >
> > One of the things I really liked about the DPDK open source project is
> > that it uses BSD licensing not GPL. Therefore, I must admit, we
> > completely failed to see that the "spirit" of the DPDK community is
> > not really BSD. Our view of this community was that the main driving
> > force of it was to be able to make DPDK run on everything anywhere
> > effectively, in a global contributing community, without  any legally
> constrains prohibiting us to do so.
>
> It is difficult to define what is the spirit of a community, especially only 
> after
> few mail exchanges.
> I agree that running on everything anywhere is a nice goal.
> Here Neil, as a RedHat developer, is probably concerned about enabling your
> driver in a distribution. It seems your model is not compatible with the
> "anywhere goal" and will be disabled in that case, until it is fully open.

The ntnic PMD is not enabled by default and I think it should not be either. To
enable it in a distribution for general purposes seems wrong. In that respect
we see no difference between the PCAP PMD and this ntnic PMD.

> > However, this is our standing, and I don't know what else to do.
> > Please advise or NAK this PMD.
>
> I do not remember having already seen such model in DPDK.
> So we need to think about the implications a bit more.
> (Comments/discussions are welcome)
> Thanks for your patience.

Thanks. I will be happy to discuss this further, so that we can get to a 
conclusion.
If the outcome is that the majority of the community does not like the idea that
upstream supported PMDs has external linking dependencies to closed source
libraries, then it is ok with us(a pity though). But then it might be a good 
idea to
make that decision clear to everybody else by putting in a clause into the
contribution section of the DPDK guide, or somewhere else in the guide.

In our opinion, the inclusion of the ntnic PMD into upstream DPDK, does not
seem to be any different than that of the PCAP PMD, since that is also
dependent on external header files and externally built libraries.
Of course we see the difference in open source vs close source library. But we
cannot see that is has any influence in the usage or functionality of the DPDK.

Thanks for this discussion!

Disclaimer: This email and any files transmitted with it may contain 
confidential information intended for the addressee(s) only. The information is 
not to be surrendered or copied to unauthorized persons. If you have 

[dpdk-dev] [PATCH v2 2/2] net/i40e: enable 25G device

[Zhang Qi]

Add code branch for 25G link speed,
so 25G device will be functional.

Signed-off-by: Zhang Qi 
---
 drivers/net/i40e/i40e_ethdev.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index fc7e128..e5b6554 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1567,6 +1567,8 @@ i40e_parse_link_speeds(uint16_t link_speeds)

if (link_speeds & ETH_LINK_SPEED_40G)
link_speed |= I40E_LINK_SPEED_40GB;
+   if (link_speeds & ETH_LINK_SPEED_25G)
+   link_speed |= I40E_LINK_SPEED_25GB;
if (link_speeds & ETH_LINK_SPEED_20G)
link_speed |= I40E_LINK_SPEED_20GB;
if (link_speeds & ETH_LINK_SPEED_10G)
@@ -1592,6 +1594,7 @@ i40e_phy_conf_link(struct i40e_hw *hw,
I40E_AQ_PHY_FLAG_PAUSE_RX |
I40E_AQ_PHY_FLAG_LOW_POWER;
const uint8_t advt = I40E_LINK_SPEED_40GB |
+   I40E_LINK_SPEED_25GB |
I40E_LINK_SPEED_10GB |
I40E_LINK_SPEED_1GB |
I40E_LINK_SPEED_100MB;
@@ -1644,7 +1647,8 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
struct rte_eth_conf *conf = >data->dev_conf;
enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);
speed = i40e_parse_link_speeds(conf->link_speeds);
-   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
+   if (link_speed != I40E_LINK_SPEED_25GB)
+   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
if (!(conf->link_speeds & ETH_LINK_SPEED_FIXED))
abilities |= I40E_AQ_PHY_AN_ENABLED;
abilities |= I40E_AQ_PHY_LINK_ENABLED;
@@ -1746,7 +1750,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
/* Apply link configure */
if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G |
-   ETH_LINK_SPEED_20G | ETH_LINK_SPEED_40G)) {
+   ETH_LINK_SPEED_20G | ETH_LINK_SPEED_25G |
+   ETH_LINK_SPEED_40G)) {
PMD_DRV_LOG(ERR, "Invalid link setting");
goto err_up;
}
@@ -1966,9 +1971,10 @@ static int
 i40e_dev_set_link_down(struct rte_eth_dev *dev)
 {
uint8_t speed = I40E_LINK_SPEED_UNKNOWN;
-   uint8_t abilities = I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
+   uint8_t abilities = 0;
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
+   if (i40e_get_link_speed_by_devid(hw->device_id) != I40E_LINK_SPEED_25GB)
+   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
return i40e_phy_conf_link(hw, abilities, speed);
 }

@@ -2026,6 +2032,9 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
case I40E_LINK_SPEED_20GB:
link.link_speed = ETH_SPEED_NUM_20G;
break;
+   case I40E_LINK_SPEED_25GB:
+   link.link_speed = ETH_SPEED_NUM_25G;
+   break;
case I40E_LINK_SPEED_40GB:
link.link_speed = ETH_SPEED_NUM_40G;
break;
@@ -2630,6 +2639,9 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
if (link_speed == I40E_LINK_SPEED_40GB)
/* For XL710 */
dev_info->speed_capa = ETH_LINK_SPEED_40G;
+   if (link_speed == I40E_LINK_SPEED_25GB)
+   /* For XXL710 */
+   dev_info->speed_capa = ETH_LINK_SPEED_25G;
else
/* For X710 */
dev_info->speed_capa = ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G;
@@ -8077,7 +8089,8 @@ i40e_configure_registers(struct i40e_hw *hw)

for (i = 0; i < RTE_DIM(reg_table); i++) {
if (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR) {
-   if (link_speed == I40E_LINK_SPEED_40GB) /* For XL710 */
+   if (link_speed == I40E_LINK_SPEED_40GB ||
+   link_speed == I40E_LINK_SPEED_25GB) /* For XL710 */
reg_table[i].val =
I40E_GL_SWR_PM_UP_THR_SF_VALUE;
else /* For X710 */
-- 
2.7.4

[dpdk-dev] [PATCH v2 1/2] net/i40e: add func to check link speed

[Zhang Qi]

Add a help function to check link speed by device ID.
Replace macro "i40e_is_40G_device" with the new function.

Signed-off-by: Zhang Qi 
---
 drivers/net/i40e/i40e_ethdev.c | 19 ---
 drivers/net/i40e/i40e_ethdev.h | 42 ++
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index acc25a2..fc7e128 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1642,7 +1642,7 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
uint8_t abilities = 0;
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_conf *conf = >data->dev_conf;
-
+   enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);
speed = i40e_parse_link_speeds(conf->link_speeds);
abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
if (!(conf->link_speeds & ETH_LINK_SPEED_FIXED))
@@ -1650,7 +1650,7 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
abilities |= I40E_AQ_PHY_LINK_ENABLED;

/* Skip changing speed on 40G interfaces, FW does not support */
-   if (i40e_is_40G_device(hw->device_id)) {
+   if (link_speed == I40E_LINK_SPEED_40GB) {
speed =  I40E_LINK_SPEED_UNKNOWN;
abilities |= I40E_AQ_PHY_AN_ENABLED;
}
@@ -2554,6 +2554,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+   enum i40e_aq_link_speed link_speed = I40E_LINK_SPEED_UNKNOWN;

dev_info->max_rx_queues = vsi->nb_qps;
dev_info->max_tx_queues = vsi->nb_qps;
@@ -2624,8 +2625,9 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
-
-   if (i40e_is_40G_device(hw->device_id))
+
+   link_speed = i40e_get_link_speed_by_devid(hw->device_id);
+   if (link_speed == I40E_LINK_SPEED_40GB)
/* For XL710 */
dev_info->speed_capa = ETH_LINK_SPEED_40G;
else
@@ -2845,6 +2847,7 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
[RTE_FC_TX_PAUSE] = I40E_FC_TX_PAUSE,
[RTE_FC_FULL] = I40E_FC_FULL
};
+   enum i40e_aq_link_speed link_speed = I40E_LINK_SPEED_UNKNOWN;

/* high_water field in the rte_eth_fc_conf using the kilobytes unit */

@@ -2872,8 +2875,9 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
err = i40e_set_fc(hw, _failure, true);
if (err < 0)
return -ENOSYS;
-
-   if (i40e_is_40G_device(hw->device_id)) {
+
+   link_speed = i40e_get_link_speed_by_devid(hw->device_id);
+   if (link_speed == I40E_LINK_SPEED_40GB) {
/* Configure flow control refresh threshold,
 * the value for stat_tx_pause_refresh_timer[8]
 * is used for global pause operation.
@@ -8069,10 +8073,11 @@ i40e_configure_registers(struct i40e_hw *hw)
uint64_t reg;
uint32_t i;
int ret;
+   enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);

for (i = 0; i < RTE_DIM(reg_table); i++) {
if (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR) {
-   if (i40e_is_40G_device(hw->device_id)) /* For XL710 */
+   if (link_speed == I40E_LINK_SPEED_40GB) /* For XL710 */
reg_table[i].val =
I40E_GL_SWR_PM_UP_THR_SF_VALUE;
else /* For X710 */
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 92c8fad..633bcdf 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -712,4 +712,46 @@ i40e_calc_itr_interval(int16_t interval)
(pctype) == I40E_FILTER_PCTYPE_NONF_IPV6_OTHER || \
(pctype) == I40E_FILTER_PCTYPE_L2_PAYLOAD)

+static inline enum i40e_aq_link_speed
+i40e_get_link_speed_by_devid(u16 dev_id)
+{
+   switch (dev_id) {
+   case I40E_DEV_ID_10G_BASE_T:
+   case I40E_DEV_ID_10G_BASE_T4:
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
+   case I40E_DEV_ID_X722_A0:
+#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
+   case I40E_DEV_ID_X722_A0_VF:
+#endif
+#endif
+   case I40E_DEV_ID_KX_X722:
+   case I40E_DEV_ID_QSFP_X722:
+   case I40E_DEV_ID_SFP_X722:
+   case I40E_DEV_ID_1G_BASE_T_X722:
+   case I40E_DEV_ID_10G_BASE_T_X722:
+   case I40E_DEV_ID_SFP_I_X722:
+#define I40E_DEV_ID_QSFP_I_X7220x37D4
+#if defined(INTEGRATED_VF) || 

[dpdk-dev] [PATCH v2 0/2] net/i40e: enable 25G device

[Zhang Qi]

The patch enable devices that support 25G link speed.
It is based on previous 25G base driver update:
http://dpdk.org/ml/archives/dev/2016-August/045569.html


Zhang Qi (2):
  net/i40e: add func to check link speed
  net/i40e: enable 25G device

 drivers/net/i40e/i40e_ethdev.c | 40 +---
 drivers/net/i40e/i40e_ethdev.h | 42 ++
 2 files changed, 71 insertions(+), 11 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 2/2] net/i40e: enable 25G device

[Zhang Qi]

Add code branch for 25G link speed,
so 25G device will be functional.

Signed-off-by: Zhang Qi 
---
 drivers/net/i40e/i40e_ethdev.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index fc7e128..e5b6554 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1567,6 +1567,8 @@ i40e_parse_link_speeds(uint16_t link_speeds)

if (link_speeds & ETH_LINK_SPEED_40G)
link_speed |= I40E_LINK_SPEED_40GB;
+   if (link_speeds & ETH_LINK_SPEED_25G)
+   link_speed |= I40E_LINK_SPEED_25GB;
if (link_speeds & ETH_LINK_SPEED_20G)
link_speed |= I40E_LINK_SPEED_20GB;
if (link_speeds & ETH_LINK_SPEED_10G)
@@ -1592,6 +1594,7 @@ i40e_phy_conf_link(struct i40e_hw *hw,
I40E_AQ_PHY_FLAG_PAUSE_RX |
I40E_AQ_PHY_FLAG_LOW_POWER;
const uint8_t advt = I40E_LINK_SPEED_40GB |
+   I40E_LINK_SPEED_25GB |
I40E_LINK_SPEED_10GB |
I40E_LINK_SPEED_1GB |
I40E_LINK_SPEED_100MB;
@@ -1644,7 +1647,8 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
struct rte_eth_conf *conf = >data->dev_conf;
enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);
speed = i40e_parse_link_speeds(conf->link_speeds);
-   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
+   if (link_speed != I40E_LINK_SPEED_25GB)
+   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
if (!(conf->link_speeds & ETH_LINK_SPEED_FIXED))
abilities |= I40E_AQ_PHY_AN_ENABLED;
abilities |= I40E_AQ_PHY_LINK_ENABLED;
@@ -1746,7 +1750,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
/* Apply link configure */
if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G |
-   ETH_LINK_SPEED_20G | ETH_LINK_SPEED_40G)) {
+   ETH_LINK_SPEED_20G | ETH_LINK_SPEED_25G |
+   ETH_LINK_SPEED_40G)) {
PMD_DRV_LOG(ERR, "Invalid link setting");
goto err_up;
}
@@ -1966,9 +1971,10 @@ static int
 i40e_dev_set_link_down(struct rte_eth_dev *dev)
 {
uint8_t speed = I40E_LINK_SPEED_UNKNOWN;
-   uint8_t abilities = I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
+   uint8_t abilities = 0;
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
+   if (i40e_get_link_speed_by_devid(hw->device_id)!=I40E_LINK_SPEED_25GB)
+   abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
return i40e_phy_conf_link(hw, abilities, speed);
 }

@@ -2026,6 +2032,9 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
case I40E_LINK_SPEED_20GB:
link.link_speed = ETH_SPEED_NUM_20G;
break;
+   case I40E_LINK_SPEED_25GB:
+   link.link_speed = ETH_SPEED_NUM_25G;
+   break;
case I40E_LINK_SPEED_40GB:
link.link_speed = ETH_SPEED_NUM_40G;
break;
@@ -2630,6 +2639,9 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
if (link_speed == I40E_LINK_SPEED_40GB)
/* For XL710 */
dev_info->speed_capa = ETH_LINK_SPEED_40G;
+   if (link_speed == I40E_LINK_SPEED_25GB)
+   /* For XXL710 */
+   dev_info->speed_capa = ETH_LINK_SPEED_25G;
else
/* For X710 */
dev_info->speed_capa = ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G;
@@ -8077,7 +8089,8 @@ i40e_configure_registers(struct i40e_hw *hw)

for (i = 0; i < RTE_DIM(reg_table); i++) {
if (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR) {
-   if (link_speed == I40E_LINK_SPEED_40GB) /* For XL710 */
+   if (link_speed == I40E_LINK_SPEED_40GB ||
+   link_speed == I40E_LINK_SPEED_25GB) /* For XL710 */
reg_table[i].val =
I40E_GL_SWR_PM_UP_THR_SF_VALUE;
else /* For X710 */
-- 
2.7.4

[dpdk-dev] [PATCH 1/2] net/i40e: add func to check link speed

[Zhang Qi]

Add a help function to check link speed by device ID.
Replace macro "i40e_is_40G_device" with the new function.

Signed-off-by: Zhang Qi 
---
 drivers/net/i40e/i40e_ethdev.c | 19 ---
 drivers/net/i40e/i40e_ethdev.h | 42 ++
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index acc25a2..fc7e128 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1642,7 +1642,7 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
uint8_t abilities = 0;
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_conf *conf = >data->dev_conf;
-
+   enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);
speed = i40e_parse_link_speeds(conf->link_speeds);
abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
if (!(conf->link_speeds & ETH_LINK_SPEED_FIXED))
@@ -1650,7 +1650,7 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
abilities |= I40E_AQ_PHY_LINK_ENABLED;

/* Skip changing speed on 40G interfaces, FW does not support */
-   if (i40e_is_40G_device(hw->device_id)) {
+   if (link_speed == I40E_LINK_SPEED_40GB) {
speed =  I40E_LINK_SPEED_UNKNOWN;
abilities |= I40E_AQ_PHY_AN_ENABLED;
}
@@ -2554,6 +2554,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+   enum i40e_aq_link_speed link_speed = I40E_LINK_SPEED_UNKNOWN;

dev_info->max_rx_queues = vsi->nb_qps;
dev_info->max_tx_queues = vsi->nb_qps;
@@ -2624,8 +2625,9 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
-
-   if (i40e_is_40G_device(hw->device_id))
+   
+   link_speed = i40e_get_link_speed_by_devid(hw->device_id);
+   if (link_speed == I40E_LINK_SPEED_40GB)
/* For XL710 */
dev_info->speed_capa = ETH_LINK_SPEED_40G;
else
@@ -2845,6 +2847,7 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
[RTE_FC_TX_PAUSE] = I40E_FC_TX_PAUSE,
[RTE_FC_FULL] = I40E_FC_FULL
};
+   enum i40e_aq_link_speed link_speed = I40E_LINK_SPEED_UNKNOWN;

/* high_water field in the rte_eth_fc_conf using the kilobytes unit */

@@ -2872,8 +2875,9 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
err = i40e_set_fc(hw, _failure, true);
if (err < 0)
return -ENOSYS;
-
-   if (i40e_is_40G_device(hw->device_id)) {
+   
+   link_speed = i40e_get_link_speed_by_devid(hw->device_id);
+   if (link_speed == I40E_LINK_SPEED_40GB) {
/* Configure flow control refresh threshold,
 * the value for stat_tx_pause_refresh_timer[8]
 * is used for global pause operation.
@@ -8069,10 +8073,11 @@ i40e_configure_registers(struct i40e_hw *hw)
uint64_t reg;
uint32_t i;
int ret;
+   enum i40e_aq_link_speed link_speed = 
i40e_get_link_speed_by_devid(hw->device_id);

for (i = 0; i < RTE_DIM(reg_table); i++) {
if (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR) {
-   if (i40e_is_40G_device(hw->device_id)) /* For XL710 */
+   if (link_speed == I40E_LINK_SPEED_40GB) /* For XL710 */
reg_table[i].val =
I40E_GL_SWR_PM_UP_THR_SF_VALUE;
else /* For X710 */
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 92c8fad..633bcdf 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -712,4 +712,46 @@ i40e_calc_itr_interval(int16_t interval)
(pctype) == I40E_FILTER_PCTYPE_NONF_IPV6_OTHER || \
(pctype) == I40E_FILTER_PCTYPE_L2_PAYLOAD)

+static inline enum i40e_aq_link_speed
+i40e_get_link_speed_by_devid(u16 dev_id)
+{
+   switch (dev_id) {
+   case I40E_DEV_ID_10G_BASE_T:
+   case I40E_DEV_ID_10G_BASE_T4:
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
+   case I40E_DEV_ID_X722_A0:
+#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
+   case I40E_DEV_ID_X722_A0_VF:
+#endif
+#endif
+   case I40E_DEV_ID_KX_X722:
+   case I40E_DEV_ID_QSFP_X722:
+   case I40E_DEV_ID_SFP_X722:
+   case I40E_DEV_ID_1G_BASE_T_X722:
+   case I40E_DEV_ID_10G_BASE_T_X722:
+   case I40E_DEV_ID_SFP_I_X722:
+#define I40E_DEV_ID_QSFP_I_X7220x37D4
+#if 

[dpdk-dev] [PATCH 0/2] net/i40e: enable 25G device

[Zhang Qi]

The patch enable devices that support 25G link speed.
It is based on previous 25G base driver update:
http://dpdk.org/ml/archives/dev/2016-August/045569.html


Zhang Qi (2):
  net/i40e: add func to check link speed
  net/i40e: enable 25G device

 drivers/net/i40e/i40e_ethdev.c | 40 +---
 drivers/net/i40e/i40e_ethdev.h | 42 ++
 2 files changed, 71 insertions(+), 11 deletions(-)

-- 
2.7.4