* [PATCH v3 00/25] Generic flow API (rte_flow)
From: Adrien Mazarguil @ 2016-12-19 17:48 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1481903839.git.adrien.mazarguil@6wind.com>
As previously discussed in RFC v1 [1], RFC v2 [2], with changes
described in [3] (also pasted below), here is the first non-draft series
for this new API.
Its capabilities are so generic that its name had to be vague, it may be
called "Generic flow API", "Generic flow interface" (possibly shortened
as "GFI") to refer to the name of the new filter type, or "rte_flow" from
the prefix used for its public symbols. I personally favor the latter.
While it is currently meant to supersede existing filter types in order for
all PMDs to expose a common filtering/classification interface, it may
eventually evolve to cover the following ideas as well:
- Rx/Tx offloads configuration through automatic offloads for specific
packets, e.g. performing checksum on TCP packets could be expressed with
an egress rule with a TCP pattern and a kind of checksum action.
- RSS configuration (already defined actually). Could be global or per rule
depending on hardware capabilities.
- Switching configuration for devices with many physical ports; rules doing
both ingress and egress could even be used to completely bypass software
if supported by hardware.
[1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
[2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
[3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
Changes since v2 series:
- Replaced ENOTSUP with ENOSYS in the code (although doing so triggers
spurious checkpatch warnings) to tell apart unimplemented callbacks from
unsupported flow rules and match the documented behavior.
- Fixed missing include seen by check-includes.sh in rte_flow_driver.h.
- Made clearer that PMDs must initialize rte_flow_error (if non-NULL) in
case of error, added related memory poisoning in testpmd to catch missing
initializations.
- Fixed rte_flow programmer's guide according to John Mcnamara's comments
(tables, sections header and typos).
- Fixed deprecation notice as well.
Changes since v1 series:
- Added programmer's guide documentation for rte_flow.
- Added depreciation notice for the legacy API.
- Documented testpmd flow command.
- Fixed missing rte_flow_flush symbol in rte_ether_version.map.
- Cleaned up API documentation in rte_flow.h.
- Replaced "min/max" parameters with "num" in struct rte_flow_item_any, to
align behavior with other item definitions.
- Fixed "type" (EtherType) size in struct rte_flow_item_eth.
- Renamed "queues" to "num" in struct rte_flow_action_rss.
- Fixed missing const in rte_flow_error_set() prototype definition.
- Fixed testpmd flow create command that did not save the rte_flow object
pointer, causing crashes.
- Hopefully fixed all the remaining ICC/clang errors.
- Replaced testpmd flow command's "fix" token with "is" for clarity.
Changes since RFC v2:
- New separate VLAN pattern item (previously part of the ETH definition),
found to be much more convenient.
- Removed useless "any" field from VF pattern item, the same effect can be
achieved by not providing a specification structure.
- Replaced bit-fields from the VXLAN pattern item to avoid endianness
conversion issues on 24-bit fields.
- Updated struct rte_flow_item with a new "last" field to create inclusive
ranges. They are defined as the interval between (spec & mask) and
(last & mask). All three parameters are optional.
- Renamed ID action MARK.
- Renamed "queue" fields in actions QUEUE and DUP to "index".
- "rss_conf" field in RSS action is now const.
- VF action now uses a 32 bit ID like its pattern item counterpart.
- Removed redundant struct rte_flow_pattern, API functions now expect
struct
rte_flow_item lists terminated by END items.
- Replaced struct rte_flow_actions for the same reason, with struct
rte_flow_action lists terminated by END actions.
- Error types (enum rte_flow_error_type) have been updated and the cause
pointer in struct rte_flow_error is now const.
- Function prototypes (rte_flow_create, rte_flow_validate) have also been
updated for clarity.
Additions:
- Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
are now implemented in rte_flow.c, with their symbols exported and
versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
- A separate header (rte_flow_driver.h) has been added for driver-side
functionality, in particular struct rte_flow_ops which contains PMD
callbacks returned by RTE_ETH_FILTER_GENERIC query.
- testpmd now exposes most of this API through the new "flow" command.
What remains to be done:
- Using endian-aware integer types (rte_beX_t) where necessary for clarity.
- API documentation (based on RFC).
- testpmd flow command documentation (although context-aware command
completion should already help quite a bit in this regard).
- A few pattern item / action properties cannot be configured yet
(e.g. rss_conf parameter for RSS action) and a few completions
(e.g. possible queue IDs) should be added.
Adrien Mazarguil (25):
ethdev: introduce generic flow API
doc: add rte_flow prog guide
doc: announce deprecation of legacy filter types
cmdline: add support for dynamic tokens
cmdline: add alignment constraint
app/testpmd: implement basic support for rte_flow
app/testpmd: add flow command
app/testpmd: add rte_flow integer support
app/testpmd: add flow list command
app/testpmd: add flow flush command
app/testpmd: add flow destroy command
app/testpmd: add flow validate/create commands
app/testpmd: add flow query command
app/testpmd: add rte_flow item spec handler
app/testpmd: add rte_flow item spec prefix length
app/testpmd: add rte_flow bit-field support
app/testpmd: add item any to flow command
app/testpmd: add various items to flow command
app/testpmd: add item raw to flow command
app/testpmd: add items eth/vlan to flow command
app/testpmd: add items ipv4/ipv6 to flow command
app/testpmd: add L4 items to flow command
app/testpmd: add various actions to flow command
app/testpmd: add queue actions to flow command
doc: describe testpmd flow command
MAINTAINERS | 4 +
app/test-pmd/Makefile | 1 +
app/test-pmd/cmdline.c | 32 +
app/test-pmd/cmdline_flow.c | 2575 ++++++++++++++++++++++
app/test-pmd/config.c | 498 +++++
app/test-pmd/csumonly.c | 1 +
app/test-pmd/flowgen.c | 1 +
app/test-pmd/icmpecho.c | 1 +
app/test-pmd/ieee1588fwd.c | 1 +
app/test-pmd/iofwd.c | 1 +
app/test-pmd/macfwd.c | 1 +
app/test-pmd/macswap.c | 1 +
app/test-pmd/parameters.c | 1 +
app/test-pmd/rxonly.c | 1 +
app/test-pmd/testpmd.c | 6 +
app/test-pmd/testpmd.h | 27 +
app/test-pmd/txonly.c | 1 +
doc/api/doxy-api-index.md | 2 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/rte_flow.rst | 2042 +++++++++++++++++
doc/guides/rel_notes/deprecation.rst | 8 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 612 +++++
lib/librte_cmdline/cmdline_parse.c | 67 +-
lib/librte_cmdline/cmdline_parse.h | 21 +
lib/librte_ether/Makefile | 3 +
lib/librte_ether/rte_eth_ctrl.h | 1 +
lib/librte_ether/rte_ether_version.map | 11 +
lib/librte_ether/rte_flow.c | 159 ++
lib/librte_ether/rte_flow.h | 947 ++++++++
lib/librte_ether/rte_flow_driver.h | 182 ++
30 files changed, 7200 insertions(+), 9 deletions(-)
create mode 100644 app/test-pmd/cmdline_flow.c
create mode 100644 doc/guides/prog_guide/rte_flow.rst
create mode 100644 lib/librte_ether/rte_flow.c
create mode 100644 lib/librte_ether/rte_flow.h
create mode 100644 lib/librte_ether/rte_flow_driver.h
--
2.1.4
^ permalink raw reply
* [PATCH v3 1/4] crypto/aesni_mb: fix incorrect crypto session
From: Pablo de Lara @ 2016-12-19 17:29 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara, stable
In-Reply-To: <1482168543-40289-1-git-send-email-pablo.de.lara.guarch@intel.com>
When using sessionless crypto operations, crypto session
is obtained from a pool of sessions, when processing the
operation. Once the operation is processed, the session
is put back in the pool, but for the AESNI MB PMD, this
session was not being saved in the operation and therefore,
it did not return to the session pool.
Fixes: 924e84f87306 ("aesni_mb: add driver for multi buffer based crypto")
CC: stable@dpdk.org
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index f07cd07..7443b47 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -322,6 +322,7 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
rte_mempool_put(qp->sess_mp, _sess);
sess = NULL;
}
+ op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
}
return sess;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/4] doc: add missing supported algos for AESNI MB PMD
From: Pablo de Lara @ 2016-12-19 17:29 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
In-Reply-To: <1482168543-40289-1-git-send-email-pablo.de.lara.guarch@intel.com>
AESNI MB PMD supports SHA224-HMAC and SHA384-HMAC,
but the documentation was not updated with this.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/cryptodevs/aesni_mb.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index cb429d7..8b18eba 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -55,7 +55,9 @@ Cipher algorithms:
Hash algorithms:
* RTE_CRYPTO_HASH_SHA1_HMAC
+* RTE_CRYPTO_HASH_SHA224_HMAC
* RTE_CRYPTO_HASH_SHA256_HMAC
+* RTE_CRYPTO_HASH_SHA384_HMAC
* RTE_CRYPTO_HASH_SHA512_HMAC
Limitations
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/4] crypto/aesni_mb: add single operation functionality
From: Pablo de Lara @ 2016-12-19 17:29 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
In-Reply-To: <1482168543-40289-1-git-send-email-pablo.de.lara.guarch@intel.com>
Update driver to use new AESNI Multibuffer IPSec library single
operation functionality (cipher only and authentication only).
This patch also adds tests for this new feature.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test/test_cryptodev.c | 34 ++++++++
app/test/test_cryptodev_aes_test_vectors.h | 36 +++++---
app/test/test_cryptodev_hash_test_vectors.h | 54 ++++++++----
doc/guides/cryptodevs/aesni_mb.rst | 2 -
doc/guides/rel_notes/release_17_02.rst | 1 +
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 95 ++++++++++++++++------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 9 ++
7 files changed, 172 insertions(+), 59 deletions(-)
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index f1f3542..5895d99 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1466,6 +1466,38 @@ test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_sym_session *sess,
}
static int
+test_AES_cipheronly_mb_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool, ts_params->valid_devs[0],
+ RTE_CRYPTODEV_AESNI_MB_PMD,
+ BLKCIPHER_AES_CIPHERONLY_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_authonly_mb_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool, ts_params->valid_devs[0],
+ RTE_CRYPTODEV_AESNI_MB_PMD,
+ BLKCIPHER_AUTHONLY_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
test_AES_chain_mb_all(void)
{
struct crypto_testsuite_params *ts_params = &testsuite_params;
@@ -6559,6 +6591,8 @@ static struct unit_test_suite cryptodev_aesni_mb_testsuite = {
.teardown = testsuite_teardown,
.unit_test_cases = {
TEST_CASE_ST(ut_setup, ut_teardown, test_AES_chain_mb_all),
+ TEST_CASE_ST(ut_setup, ut_teardown, test_AES_cipheronly_mb_all),
+ TEST_CASE_ST(ut_setup, ut_teardown, test_authonly_mb_all),
TEST_CASES_END() /**< NULL terminate unit test array */
}
diff --git a/app/test/test_cryptodev_aes_test_vectors.h b/app/test/test_cryptodev_aes_test_vectors.h
index efbe7da..898aae1 100644
--- a/app/test/test_cryptodev_aes_test_vectors.h
+++ b/app/test/test_cryptodev_aes_test_vectors.h
@@ -1025,84 +1025,96 @@ static const struct blockcipher_test_case aes_cipheronly_test_cases[] = {
.test_data = &aes_test_data_4,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-128-CBC Decryption",
.test_data = &aes_test_data_4,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-192-CBC Encryption",
.test_data = &aes_test_data_10,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-192-CBC Decryption",
.test_data = &aes_test_data_10,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-256-CBC Encryption",
.test_data = &aes_test_data_11,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-256-CBC Decryption",
.test_data = &aes_test_data_11,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-128-CTR Encryption",
.test_data = &aes_test_data_1,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-128-CTR Decryption",
.test_data = &aes_test_data_1,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-192-CTR Encryption",
.test_data = &aes_test_data_2,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-192-CTR Decryption",
.test_data = &aes_test_data_2,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-256-CTR Encryption",
.test_data = &aes_test_data_3,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "AES-256-CTR Decryption",
.test_data = &aes_test_data_3,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
- BLOCKCIPHER_TEST_TARGET_PMD_QAT
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
};
diff --git a/app/test/test_cryptodev_hash_test_vectors.h b/app/test/test_cryptodev_hash_test_vectors.h
index 9f095cf..a8f9da0 100644
--- a/app/test/test_cryptodev_hash_test_vectors.h
+++ b/app/test/test_cryptodev_hash_test_vectors.h
@@ -97,7 +97,8 @@ hmac_md5_test_vector = {
0x50, 0xE8, 0xDE, 0xC5, 0xC1, 0x76, 0xAC, 0xAE,
0x15, 0x4A, 0xF1, 0x7F, 0x7E, 0x04, 0x42, 0x9B
},
- .len = 16
+ .len = 16,
+ .truncated_len = 12
}
};
@@ -139,7 +140,8 @@ hmac_sha1_test_vector = {
0x7E, 0x2E, 0x8F, 0xFC, 0x48, 0x39, 0x46, 0x17,
0x3F, 0x91, 0x64, 0x59
},
- .len = 20
+ .len = 20,
+ .truncated_len = 12
}
};
@@ -184,7 +186,8 @@ hmac_sha224_test_vector = {
0xF1, 0x8A, 0x63, 0xBB, 0x5D, 0x1D, 0xE3, 0x9F,
0x92, 0xF6, 0xAA, 0x19
},
- .len = 28
+ .len = 28,
+ .truncated_len = 14
}
};
@@ -229,7 +232,8 @@ hmac_sha256_test_vector = {
0x06, 0x4D, 0x64, 0x09, 0x0A, 0xCC, 0x02, 0x77,
0x71, 0x83, 0x48, 0x71, 0x07, 0x02, 0x25, 0x17
},
- .len = 32
+ .len = 32,
+ .truncated_len = 16
}
};
@@ -280,7 +284,8 @@ hmac_sha384_test_vector = {
0x10, 0x90, 0x0A, 0xE3, 0xF0, 0x59, 0xDD, 0xC0,
0x6F, 0xE6, 0x8C, 0x84, 0xD5, 0x03, 0xF8, 0x9E
},
- .len = 48
+ .len = 48,
+ .truncated_len = 24
}
};
@@ -337,7 +342,8 @@ hmac_sha512_test_vector = {
0x97, 0x37, 0x0F, 0xBE, 0xC2, 0x45, 0xA0, 0x87,
0xAF, 0x24, 0x27, 0x0C, 0x78, 0xBA, 0xBE, 0x20
},
- .len = 64
+ .len = 64,
+ .truncated_len = 32
}
};
@@ -358,13 +364,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-MD5 Digest",
.test_data = &hmac_md5_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-MD5 Digest Verify",
.test_data = &hmac_md5_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "SHA1 Digest",
@@ -382,13 +390,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-SHA1 Digest",
.test_data = &hmac_sha1_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-SHA1 Digest Verify",
.test_data = &hmac_sha1_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "SHA224 Digest",
@@ -406,13 +416,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-SHA224 Digest",
.test_data = &hmac_sha224_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-SHA224 Digest Verify",
.test_data = &hmac_sha224_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "SHA256 Digest",
@@ -430,13 +442,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-SHA256 Digest",
.test_data = &hmac_sha256_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-SHA256 Digest Verify",
.test_data = &hmac_sha256_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "SHA384 Digest",
@@ -454,13 +468,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-SHA384 Digest",
.test_data = &hmac_sha384_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-SHA384 Digest Verify",
.test_data = &hmac_sha384_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "SHA512 Digest",
@@ -478,13 +494,15 @@ static const struct blockcipher_test_case hash_test_cases[] = {
.test_descr = "HMAC-SHA512 Digest",
.test_data = &hmac_sha512_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_GEN,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
{
.test_descr = "HMAC-SHA512 Digest Verify",
.test_data = &hmac_sha512_test_vector,
.op_mask = BLOCKCIPHER_TEST_OP_AUTH_VERIFY,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_MB
},
};
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index b47cb6a..cb429d7 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -62,8 +62,6 @@ Limitations
-----------
* Chained mbufs are not supported.
-* Hash only is not supported.
-* Cipher only is not supported.
* Only in-place is currently supported (destination address is the same as source address).
* Only supports session-oriented API implementation (session-less APIs are not supported).
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 4f666df..5aa8a94 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -49,6 +49,7 @@ New Features
* The Intel(R) Multi Buffer Crypto for IPsec library used in
AESNI MB PMD has been moved to a new repository, in github.
+ * Support for single operations (cipher only and authentication only).
Resolved Issues
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 7443b47..bafd4d7 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -107,26 +107,27 @@ calculate_auth_precomputes(hash_one_block_t one_block_hash,
}
/** Get xform chain order */
-static int
+static enum aesni_mb_operation
aesni_mb_get_chain_order(const struct rte_crypto_sym_xform *xform)
{
- /*
- * Multi-buffer only supports HASH_CIPHER or CIPHER_HASH chained
- * operations, all other options are invalid, so we must have exactly
- * 2 xform structs chained together
- */
- if (xform->next == NULL || xform->next->next != NULL)
- return -1;
-
- if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
- xform->next->type == RTE_CRYPTO_SYM_XFORM_CIPHER)
- return HASH_CIPHER;
+ if (xform == NULL)
+ return AESNI_MB_OP_NOT_SUPPORTED;
+
+ if (xform->type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
+ if (xform->next == NULL)
+ return AESNI_MB_OP_CIPHER_ONLY;
+ if (xform->next->type == RTE_CRYPTO_SYM_XFORM_AUTH)
+ return AESNI_MB_OP_CIPHER_HASH;
+ }
- if (xform->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
- xform->next->type == RTE_CRYPTO_SYM_XFORM_AUTH)
- return CIPHER_HASH;
+ if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
+ if (xform->next == NULL)
+ return AESNI_MB_OP_HASH_ONLY;
+ if (xform->next->type == RTE_CRYPTO_SYM_XFORM_CIPHER)
+ return AESNI_MB_OP_HASH_CIPHER;
+ }
- return -1;
+ return AESNI_MB_OP_NOT_SUPPORTED;
}
/** Set session authentication parameters */
@@ -137,11 +138,19 @@ aesni_mb_set_session_auth_parameters(const struct aesni_mb_ops *mb_ops,
{
hash_one_block_t hash_oneblock_fn;
+ if (xform == NULL) {
+ sess->auth.algo = NULL_HASH;
+ return 0;
+ }
+
if (xform->type != RTE_CRYPTO_SYM_XFORM_AUTH) {
MB_LOG_ERR("Crypto xform struct not of type auth");
return -1;
}
+ /* Select auth generate/verify */
+ sess->auth.operation = xform->auth.op;
+
/* Set Authentication Parameters */
if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_XCBC_MAC) {
sess->auth.algo = AES_XCBC;
@@ -199,6 +208,11 @@ aesni_mb_set_session_cipher_parameters(const struct aesni_mb_ops *mb_ops,
{
aes_keyexp_t aes_keyexp_fn;
+ if (xform == NULL) {
+ sess->cipher.mode = NULL_CIPHER;
+ return 0;
+ }
+
if (xform->type != RTE_CRYPTO_SYM_XFORM_CIPHER) {
MB_LOG_ERR("Crypto xform struct not of type cipher");
return -1;
@@ -268,16 +282,36 @@ aesni_mb_set_session_parameters(const struct aesni_mb_ops *mb_ops,
/* Select Crypto operation - hash then cipher / cipher then hash */
switch (aesni_mb_get_chain_order(xform)) {
- case HASH_CIPHER:
+ case AESNI_MB_OP_HASH_CIPHER:
sess->chain_order = HASH_CIPHER;
auth_xform = xform;
cipher_xform = xform->next;
break;
- case CIPHER_HASH:
+ case AESNI_MB_OP_CIPHER_HASH:
sess->chain_order = CIPHER_HASH;
auth_xform = xform->next;
cipher_xform = xform;
break;
+ case AESNI_MB_OP_HASH_ONLY:
+ sess->chain_order = HASH_CIPHER;
+ auth_xform = xform;
+ cipher_xform = NULL;
+ break;
+ case AESNI_MB_OP_CIPHER_ONLY:
+ /*
+ * Multi buffer library operates only at two modes,
+ * CIPHER_HASH and HASH_CIPHER. When doing ciphering only,
+ * chain order depends on cipher operation: encryption is always
+ * the first operation and decryption the last one.
+ */
+ if (xform->cipher.op == RTE_CRYPTO_CIPHER_OP_ENCRYPT)
+ sess->chain_order = CIPHER_HASH;
+ else
+ sess->chain_order = HASH_CIPHER;
+ auth_xform = NULL;
+ cipher_xform = xform;
+ break;
+ case AESNI_MB_OP_NOT_SUPPORTED:
default:
MB_LOG_ERR("Unsupported operation chain order parameter");
return -1;
@@ -397,7 +431,8 @@ process_crypto_op(struct aesni_mb_qp *qp, struct rte_crypto_op *op,
}
/* Set digest output location */
- if (job->cipher_direction == DECRYPT) {
+ if (job->hash_alg != NULL_HASH &&
+ session->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
job->auth_tag_output = (uint8_t *)rte_pktmbuf_append(m_dst,
get_digest_byte_length(job->hash_alg));
@@ -459,6 +494,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
(struct rte_crypto_op *)job->user_data;
struct rte_mbuf *m_dst =
(struct rte_mbuf *)job->user_data2;
+ struct aesni_mb_session *sess;
if (op == NULL || m_dst == NULL)
return NULL;
@@ -470,14 +506,19 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
if (unlikely(job->status != STS_COMPLETED)) {
op->status = RTE_CRYPTO_OP_STATUS_ERROR;
return op;
- } else if (job->chain_order == HASH_CIPHER) {
- /* Verify digest if required */
- if (memcmp(job->auth_tag_output, op->sym->auth.digest.data,
- job->auth_tag_output_len_in_bytes) != 0)
- op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
-
- /* trim area used for digest from mbuf */
- rte_pktmbuf_trim(m_dst, get_digest_byte_length(job->hash_alg));
+ } else if (job->hash_alg != NULL_HASH) {
+ sess = (struct aesni_mb_session *)op->sym->session->_private;
+ if (sess->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
+ /* Verify digest if required */
+ if (memcmp(job->auth_tag_output,
+ op->sym->auth.digest.data,
+ job->auth_tag_output_len_in_bytes) != 0)
+ op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
+
+ /* trim area used for digest from mbuf */
+ rte_pktmbuf_trim(m_dst,
+ get_digest_byte_length(job->hash_alg));
+ }
}
/* Free session if a session-less crypto op */
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
index 17f367f..5f125b2 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -125,6 +125,13 @@ get_digest_byte_length(JOB_HASH_ALG algo)
return auth_digest_byte_lengths[algo];
}
+enum aesni_mb_operation {
+ AESNI_MB_OP_HASH_CIPHER,
+ AESNI_MB_OP_CIPHER_HASH,
+ AESNI_MB_OP_HASH_ONLY,
+ AESNI_MB_OP_CIPHER_ONLY,
+ AESNI_MB_OP_NOT_SUPPORTED
+};
/** private data structure for each virtual AESNI device */
struct aesni_mb_private {
@@ -185,6 +192,8 @@ struct aesni_mb_session {
/** Authentication Parameters */
struct {
JOB_HASH_ALG algo; /**< Authentication Algorithm */
+ enum rte_crypto_auth_operation operation;
+ /**< auth operation generate or verify */
union {
struct {
uint8_t inner[128] __rte_aligned(16);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/4] doc: update AESNI MB PMD guide
From: Pablo de Lara @ 2016-12-19 17:29 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
In-Reply-To: <1482168543-40289-1-git-send-email-pablo.de.lara.guarch@intel.com>
The Intel(R) Multi Buffer Crypto library used in the AESNI MB PMD
has been moved to a new repository, in github.
This patch updates the link where it can be downloaded.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/cryptodevs/aesni_mb.rst | 10 +++-------
doc/guides/rel_notes/release_17_02.rst | 7 +++++++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index e812e95..b47cb6a 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -66,21 +66,17 @@ Limitations
* Cipher only is not supported.
* Only in-place is currently supported (destination address is the same as source address).
* Only supports session-oriented API implementation (session-less APIs are not supported).
-* Not performance tuned.
Installation
------------
To build DPDK with the AESNI_MB_PMD the user is required to download the mult-
-buffer library from `here <https://downloadcenter.intel.com/download/22972>`_
-and compile it on their user system before building DPDK. When building the
-multi-buffer library it is necessary to have YASM package installed and also
-requires the overriding of YASM path when building, as a path is hard coded in
-the Makefile of the release package.
+buffer library from `here <https://github.com/01org/intel-ipsec-mb>`_
+and compile it on their user system before building DPDK.
.. code-block:: console
- make YASM=/usr/bin/yasm
+ make
Initialization
--------------
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 873333b..4f666df 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -44,6 +44,13 @@ New Features
* Scatter-gather list (SGL) support.
+
+* **Updated the AESNI MB PMD.**
+
+ * The Intel(R) Multi Buffer Crypto for IPsec library used in
+ AESNI MB PMD has been moved to a new repository, in github.
+
+
Resolved Issues
---------------
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/4] AESNI MB PMD updates
From: Pablo de Lara @ 2016-12-19 17:28 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
In-Reply-To: <1481817632-183082-1-git-send-email-pablo.de.lara.guarch@intel.com>
The library used in AESNI MB PMD, Intel Multi Buffer Crypto for IPsec,
has been migrated to a new location, in github (see documentation patch
for the link).
The library has also been updated, so single crypto operations
are supported (cipher and authentication only). Therefore, the PMD
has been updated to support these operations.
This patchset depends on patchset "Add scatter-gather list capability to
Intel QuickAssist Technology driver" (http://dpdk.org/ml/archives/dev/2016-November/050947.html)
Changes in v3:
- Included authentication operation in private session,
since digest only has to be trimmed from buffer when digest is verified
- Fixed missing crypto session save in crypto operation when it is sessionless
- Made operation mode setting more clear (CIPHER_HASH, HASH_CIPHER)
Changes in v2:
- Fixed hash only tests, including truncated digest length
Pablo de Lara (4):
crypto/aesni_mb: fix incorrect crypto session
doc: update AESNI MB PMD guide
crypto/aesni_mb: add single operation functionality
doc: add missing supported algos for AESNI MB PMD
app/test/test_cryptodev.c | 34 ++++++++
app/test/test_cryptodev_aes_test_vectors.h | 36 +++++---
app/test/test_cryptodev_hash_test_vectors.h | 54 ++++++++----
doc/guides/cryptodevs/aesni_mb.rst | 14 ++--
doc/guides/rel_notes/release_17_02.rst | 8 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 96 ++++++++++++++++------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 9 ++
7 files changed, 185 insertions(+), 66 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] gitignore: ignore top level build/ directory
From: Bruce Richardson @ 2016-12-19 17:14 UTC (permalink / raw)
To: Mcnamara, John; +Cc: Thomas Monjalon, Baruch Siach, Yigit, Ferruh, dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE2026891C2@IRSMSX103.ger.corp.intel.com>
On Mon, Dec 19, 2016 at 04:50:57PM +0000, Mcnamara, John wrote:
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Monday, December 19, 2016 4:14 PM
> > To: Thomas Monjalon <thomas.monjalon@6wind.com>
> > Cc: Baruch Siach <baruch@tkos.co.il>; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] gitignore: ignore top level build/
> > directory
> >
> > On Mon, Dec 19, 2016 at 03:05:20PM +0100, Thomas Monjalon wrote:
> > > 2016-12-13 12:02, Ferruh Yigit:
> > > > On 12/13/2016 11:48 AM, Baruch Siach wrote:
> > > > > RTE_OUTPUT defaults to build/.
> > > > >
> > > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > >
> > > > There is a similar patch:
> > > > http://dpdk.org/dev/patchwork/patch/11637/
> > > >
> > > > If you want you can review/comment that one too.
> > >
> > > Yes, sorry I've never commented above patch.
> > >
> > > I do not like filling .gitignore because I prefer seeing what is built
> > > or copied or whatever with "git status".
> > > What is really the benefit of .gitignore?
> >
> > I take the opposite view. I only like to see files that I actually care
> > about in the git status. Any build artifacts should be ignored by git as
> > they are not files that it ever should track. That way doing a build does
> > not change the status of the repo as git sees it.
>
> As a workaround I have the following in my .gitconfig:
>
> [core]
> excludesfile = ~/.gitignore
>
> Then I put the ignore rules in ~/.gitignore.
>
> John
>
Yes, I have something similar done, so this is not a problem for me
personally. I just find it strange that we don't make more use of
gitignore in DPDK. The file's name itself seems to imply that it should
be used to list out files that git should not track, and build output is
definitely one of those.
/Bruce
^ permalink raw reply
* Re: [PATCH v5 18/29] app/testpmd: use VFD APIs on i40e
From: Ferruh Yigit @ 2016-12-19 17:09 UTC (permalink / raw)
To: dev; +Cc: Jingjing Wu, Helin Zhang, Wenzhuo Lu, Chen Jing D,
Bernard Iremonger
In-Reply-To: <20161216190257.6921-19-ferruh.yigit@intel.com>
On 12/16/2016 7:02 PM, Ferruh Yigit wrote:
> From: Wenzhuo Lu <wenzhuo.lu@intel.com>
>
> The new VF Daemon (VFD) APIs is implemented on i40e. Change
> testpmd code to use them, including VF MAC anti-spoofing,
> VF VLAN anti-spoofing, TX loopback, VF VLAN strip, VF VLAN
> insert.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> app/test-pmd/Makefile | 2 +
> app/test-pmd/cmdline.c | 150 +++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 121 insertions(+), 31 deletions(-)
>
> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> index 891b85a..a0c3366 100644
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -58,7 +58,9 @@ SRCS-y += csumonly.c
> SRCS-y += icmpecho.c
> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>
> +_LDLIBS-y += --whole-archive
Hi Wenzhuo,
Following lines are required for shared library, but I guess above line
required because they cause problem with static library.
So, instead of adding above line, what do you think wrapping below lines
with ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ?
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
>
> CFLAGS_cmdline.o := -D_GNU_SOURCE
>
<...>
^ permalink raw reply
* Re: [PATCH v2] maintainers: update for qede PMD and bnx2x PMD
From: Thomas Monjalon @ 2016-12-19 16:54 UTC (permalink / raw)
To: Rasesh Mody; +Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1481138539-3563-1-git-send-email-Rasesh.Mody@cavium.com>
2016-12-07 11:22, Rasesh Mody:
> Following Cavium's acquisition of QLogic we need to update all the
> qlogic PMD maintainer's entries to point to our new e-mail addresses.
> Update driver's maintainers as they are no longer working for Cavium.
>
> Thanks to Sony Chacko for his support and development of our various
> dpdk drivers.
>
> Signed-off-by: Rasesh Mody <Rasesh.Mody@cavium.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] gitignore: ignore top level build/ directory
From: Mcnamara, John @ 2016-12-19 16:50 UTC (permalink / raw)
To: Richardson, Bruce, Thomas Monjalon
Cc: Baruch Siach, Yigit, Ferruh, dev@dpdk.org
In-Reply-To: <20161219161422.GB166228@bricha3-MOBL3.ger.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Monday, December 19, 2016 4:14 PM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: Baruch Siach <baruch@tkos.co.il>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] gitignore: ignore top level build/
> directory
>
> On Mon, Dec 19, 2016 at 03:05:20PM +0100, Thomas Monjalon wrote:
> > 2016-12-13 12:02, Ferruh Yigit:
> > > On 12/13/2016 11:48 AM, Baruch Siach wrote:
> > > > RTE_OUTPUT defaults to build/.
> > > >
> > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > >
> > > There is a similar patch:
> > > http://dpdk.org/dev/patchwork/patch/11637/
> > >
> > > If you want you can review/comment that one too.
> >
> > Yes, sorry I've never commented above patch.
> >
> > I do not like filling .gitignore because I prefer seeing what is built
> > or copied or whatever with "git status".
> > What is really the benefit of .gitignore?
>
> I take the opposite view. I only like to see files that I actually care
> about in the git status. Any build artifacts should be ignored by git as
> they are not files that it ever should track. That way doing a build does
> not change the status of the repo as git sees it.
As a workaround I have the following in my .gitconfig:
[core]
excludesfile = ~/.gitignore
Then I put the ignore rules in ~/.gitignore.
John
^ permalink raw reply
* Re: [PATCH] nfp: extend speed capabilities advertised
From: Ferruh Yigit @ 2016-12-19 16:43 UTC (permalink / raw)
To: Alejandro Lucero; +Cc: dev
In-Reply-To: <CAD+H992J5mossfmWG1wq-1YE=12uAQq-R8STX-G42vv13--GBQ@mail.gmail.com>
On 12/19/2016 4:18 PM, Alejandro Lucero wrote:
> On Mon, Dec 19, 2016 at 3:05 PM, Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
>
>> On 12/19/2016 3:02 PM, Alejandro Lucero wrote:
>>>
>>>
>>> On Mon, Dec 19, 2016 at 2:36 PM, Ferruh Yigit <ferruh.yigit@intel.com
>>> <mailto:ferruh.yigit@intel.com>> wrote:
>>>
>>> Hi Alejandro,
>>>
>>>
>>> Hi,
>>>
>>>
>>> On 12/19/2016 12:05 PM, Alejandro Lucero wrote:
>>> > NFP supports more speeds than just 40 and 100GB, which were
>>> > what was advertised before.
>>> >
>>> > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com
>> <mailto:alejandro.lucero@netronome.com>>
>>> > ---
>>> > drivers/net/nfp/nfp_net.c | 4 +++-
>>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
>>> > index 27afbfd..77015c4 100644
>>> > --- a/drivers/net/nfp/nfp_net.c
>>> > +++ b/drivers/net/nfp/nfp_net.c
>>> > @@ -1077,7 +1077,9 @@ static void nfp_net_read_mac(struct
>> nfp_net_hw *hw)
>>> > dev_info->reta_size = NFP_NET_CFG_RSS_ITBL_SZ;
>>> > dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
>>> >
>>> > - dev_info->speed_capa = ETH_LINK_SPEED_40G |
>> ETH_LINK_SPEED_100G;
>>> > + dev_info->speed_capa = ETH_SPEED_NUM_1G | ETH_LINK_SPEED_10G
>> |
>>> > + ETH_SPEED_NUM_25G | ETH_SPEED_NUM_40G
>> |
>>> > + ETH_SPEED_NUM_50G |
>> ETH_LINK_SPEED_100G;
>>>
>>> Does all devices driver by this driver supports all these speeds?
>>>
>>> I am aware of at least one exception to this, from previous patch
>> [1],
>>> should we take that into account?
>>>
>>>
>>> So we have different NFP devices and different firmwares.
>>> NFP by design support all those speeds, but the PMD relies on the
>>> firmware for being able to know which is the current configured speed
>>> after link negotiation. PMD development was done with a specific
>>> firmware, and I was told to just report such speed by default. Last
>>> firmware versions give that speed info, but old firmware versions do not.
>>>
>>> So, all devices support such a speed range, indeed PMD works with any of
>>> them, but reported speed is always 40G with old firmware. This is a
>>> firmware limitation but we have to support old and new firmware.
>>
>> But this information to the application will be wrong for some (old) FW.
>> What do you think checking the FW version here and report capability
>> based on what FW supports?
>>
>>
> The driver advertises the right speed range supported. The problem is with
> the report about the current link speed configured.
> Maybe, is the right thing to do here to not report the current link speed
> because the driver really does not know about it?
Sorry, confused. Is it like following:
"
For new FW, there is no problem, it supports the range between 1G - 50G,
and reports correct current speed.
With old FW, device still can be set to speed range between 1G - 50G,
but it doesn't report current speed correct, and DPDK driver reports
back to application as device current speed is 40G, without really
knowing the current speed.
"
Thanks,
ferruh
>
> If you agree with this, I'm afraid the just accepted patch about the link
> report needs to be modified.
>
>
>
>>>
>>>
>>>
>>> Also other than that exception, can you please confirm all other
>> devices
>>> support all above speeds?
>>>
>>> [1]
>>> + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
>>> + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
>>> + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
>>> + link.link_speed = ETH_SPEED_NUM_40G;
>>>
>>>
>>> > }
>>> >
>>> > static const uint32_t *
>>> >
>>>
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH] gitignore: ignore top level build/ directory
From: Thomas Monjalon @ 2016-12-19 16:38 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Baruch Siach, Ferruh Yigit, dev
In-Reply-To: <20161219161422.GB166228@bricha3-MOBL3.ger.corp.intel.com>
2016-12-19 16:14, Bruce Richardson:
> On Mon, Dec 19, 2016 at 03:05:20PM +0100, Thomas Monjalon wrote:
> > 2016-12-13 12:02, Ferruh Yigit:
> > > On 12/13/2016 11:48 AM, Baruch Siach wrote:
> > > > RTE_OUTPUT defaults to build/.
> > > >
> > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > >
> > > There is a similar patch:
> > > http://dpdk.org/dev/patchwork/patch/11637/
> > >
> > > If you want you can review/comment that one too.
> >
> > Yes, sorry I've never commented above patch.
> >
> > I do not like filling .gitignore because I prefer
> > seeing what is built or copied or whatever with "git status".
> > What is really the benefit of .gitignore?
>
> I take the opposite view. I only like to see files that I actually care
> about in the git status. Any build artifacts should be ignored by git as
> they are not files that it ever should track. That way doing a build
> does not change the status of the repo as git sees it.
I use git status to see also the untracked files.
And build/ is just the default build directory.
^ permalink raw reply
* Re: [PATCH] nfp: extend speed capabilities advertised
From: Marc @ 2016-12-19 16:35 UTC (permalink / raw)
To: Alejandro Lucero; +Cc: Ferruh Yigit, dev
In-Reply-To: <CAD+H992J5mossfmWG1wq-1YE=12uAQq-R8STX-G42vv13--GBQ@mail.gmail.com>
On 19 December 2016 at 17:18, Alejandro Lucero <
alejandro.lucero@netronome.com> wrote:
> On Mon, Dec 19, 2016 at 3:05 PM, Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
>
> > On 12/19/2016 3:02 PM, Alejandro Lucero wrote:
> > >
> > >
> > > On Mon, Dec 19, 2016 at 2:36 PM, Ferruh Yigit <ferruh.yigit@intel.com
> > > <mailto:ferruh.yigit@intel.com>> wrote:
> > >
> > > Hi Alejandro,
> > >
> > >
> > > Hi,
> > >
> > >
> > > On 12/19/2016 12:05 PM, Alejandro Lucero wrote:
> > > > NFP supports more speeds than just 40 and 100GB, which were
> > > > what was advertised before.
> > > >
> > > > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com
> > <mailto:alejandro.lucero@netronome.com>>
> > > > ---
> > > > drivers/net/nfp/nfp_net.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/nfp/nfp_net.c
> b/drivers/net/nfp/nfp_net.c
> > > > index 27afbfd..77015c4 100644
> > > > --- a/drivers/net/nfp/nfp_net.c
> > > > +++ b/drivers/net/nfp/nfp_net.c
> > > > @@ -1077,7 +1077,9 @@ static void nfp_net_read_mac(struct
> > nfp_net_hw *hw)
> > > > dev_info->reta_size = NFP_NET_CFG_RSS_ITBL_SZ;
> > > > dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
> > > >
> > > > - dev_info->speed_capa = ETH_LINK_SPEED_40G |
> > ETH_LINK_SPEED_100G;
> > > > + dev_info->speed_capa = ETH_SPEED_NUM_1G |
> ETH_LINK_SPEED_10G
> > |
> > > > + ETH_SPEED_NUM_25G |
> ETH_SPEED_NUM_40G
> > |
> > > > + ETH_SPEED_NUM_50G |
> > ETH_LINK_SPEED_100G;
> > >
> > > Does all devices driver by this driver supports all these speeds?
> > >
> > > I am aware of at least one exception to this, from previous patch
> > [1],
> > > should we take that into account?
> > >
> > >
> > > So we have different NFP devices and different firmwares.
> > > NFP by design support all those speeds, but the PMD relies on the
> > > firmware for being able to know which is the current configured speed
> > > after link negotiation. PMD development was done with a specific
> > > firmware, and I was told to just report such speed by default. Last
> > > firmware versions give that speed info, but old firmware versions do
> not.
> > >
> > > So, all devices support such a speed range, indeed PMD works with any
> of
> > > them, but reported speed is always 40G with old firmware. This is a
> > > firmware limitation but we have to support old and new firmware.
> >
> > But this information to the application will be wrong for some (old) FW.
> > What do you think checking the FW version here and report capability
> > based on what FW supports?
> >
> >
> The driver advertises the right speed range supported. The problem is with
> the report about the current link speed configured.
> Maybe, is the right thing to do here to not report the current link speed
> because the driver really does not know about it?
>
> If you agree with this, I'm afraid the just accepted patch about the link
> report needs to be modified.
>
Alejandro,
If negociated link state has to be changed, then struct rte_eth_dev_data
dev_link field is where to do it.
As Ferruh was saying, dev_info->speed_capa contains the speed capabilties
of the particular NIC in use, not the driver (detecting firmware version
would be the best here).
marc
>
>
>
> > >
> > >
> > >
> > > Also other than that exception, can you please confirm all other
> > devices
> > > support all above speeds?
> > >
> > > [1]
> > > + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
> > > + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
> > > + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
> > > + link.link_speed = ETH_SPEED_NUM_40G;
> > >
> > >
> > > > }
> > > >
> > > > static const uint32_t *
> > > >
> > >
> > >
> >
> >
>
^ permalink raw reply
* [PATCH] doc: simplify L3fwd user guide examples
From: Pablo de Lara @ 2016-12-19 16:34 UTC (permalink / raw)
To: john.mcnamara; +Cc: dev, Pablo de Lara
L3 Forwarding sample app user guides have some inconsistencies
between the example command line and the configuration table.
Also, they were showing too complicated configuration, using two
different NUMA nodes for two ports, which will probably lead
to performance drop due to use cross-socket channel.
This patch simplifies the configuration of these examples,
by using a single NUMA node and a single queue per port.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
doc/guides/sample_app_ug/l3_forward.rst | 28 +++++--------
.../sample_app_ug/l3_forward_access_ctrl.rst | 47 ++++++++--------------
doc/guides/sample_app_ug/l3_forward_virtual.rst | 23 ++++-------
3 files changed, 34 insertions(+), 64 deletions(-)
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index ab916b9..6a6b8fb 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -129,43 +129,33 @@ Where,
* ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type.
-For example, consider a dual processor socket platform where cores 0-7 and 16-23 appear on socket 0, while cores 8-15 and 24-31 appear on socket 1.
-Let's say that the programmer wants to use memory from both NUMA nodes, the platform has only two ports, one connected to each NUMA node,
-and the programmer wants to use two cores from each processor socket to do the packet processing.
+For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0,
+while cores 8-15 and 24-31 appear on socket 1.
-To enable L3 forwarding between two ports, using two cores, cores 1 and 2, from each processor,
-while also taking advantage of local memory access by optimizing around NUMA, the programmer must enable two queues from each port,
-pin to the appropriate cores and allocate memory from the appropriate NUMA node. This is achieved using the following command:
+To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
+(which are in the same socket too), use the following command:
.. code-block:: console
- ./build/l3fwd -c 606 -n 4 -- -p 0x3 --config="(0,0,1),(0,1,2),(1,0,9),(1,1,10)"
+ ./build/l3fwd -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)"
In this command:
-* The -c option enables cores 0, 1, 2, 3
+* The -l option enables cores 1, 2
* The -p option enables ports 0 and 1
-* The --config option enables two queues on each port and maps each (port,queue) pair to a specific core.
- Logic to enable multiple RX queues using RSS and to allocate memory from the correct NUMA nodes
- is included in the application and is done transparently.
+* The --config option enables one queue on each port and maps each (port,queue) pair to a specific core.
The following table shows the mapping in this example:
+----------+-----------+-----------+-------------------------------------+
| **Port** | **Queue** | **lcore** | **Description** |
| | | | |
+----------+-----------+-----------+-------------------------------------+
-| 0 | 0 | 0 | Map queue 0 from port 0 to lcore 0. |
+| 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1. |
| | | | |
+----------+-----------+-----------+-------------------------------------+
-| 0 | 1 | 2 | Map queue 1 from port 0 to lcore 2. |
-| | | | |
-+----------+-----------+-----------+-------------------------------------+
-| 1 | 0 | 1 | Map queue 0 from port 1 to lcore 1. |
-| | | | |
-+----------+-----------+-----------+-------------------------------------+
-| 1 | 1 | 3 | Map queue 1 from port 1 to lcore 3. |
+| 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2. |
| | | | |
+----------+-----------+-----------+-------------------------------------+
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4049e01..3574a25 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -306,48 +306,35 @@ where,
* --no-numa: optional, disables numa awareness
-As an example, consider a dual processor socket platform where cores 0, 2, 4, 6, 8 and 10 appear on socket 0,
-while cores 1, 3, 5, 7, 9 and 11 appear on socket 1.
-Let's say that the user wants to use memory from both NUMA nodes,
-the platform has only two ports and the user wants to use two cores from each processor socket to do the packet processing.
+For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0,
+while cores 8-15 and 24-31 appear on socket 1.
-To enable L3 forwarding between two ports, using two cores from each processor,
-while also taking advantage of local memory access by optimizing around NUMA,
-the user must enable two queues from each port,
-pin to the appropriate cores and allocate memory from the appropriate NUMA node.
-This is achieved using the following command:
+To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
+(which are in the same socket too), use the following command:
.. code-block:: console
- ./build/l3fwd-acl -c f -n 4 -- -p 0x3 --config="(0,0,0),(0,1,2),(1,0,1),(1,1,3)" --rule_ipv4="./rule_ipv4.db" -- rule_ipv6="./rule_ipv6.db" --scalar
+ ./build/l3fwd-acl -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)" --rule_ipv4="./rule_ipv4.db" -- rule_ipv6="./rule_ipv6.db" --scalar
In this command:
-* The -c option enables cores 0, 1, 2, 3
+* The -c option enables cores 1, 2
* The -p option enables ports 0 and 1
-* The --config option enables two queues on each port and maps each (port,queue) pair to a specific core.
- Logic to enable multiple RX queues using RSS and to allocate memory from the correct NUMA nodes is included in the application
- and is done transparently.
+* The --config option enables one queue on each port and maps each (port,queue) pair to a specific core.
The following table shows the mapping in this example:
- +----------+------------+-----------+------------------------------------------------+
- | **Port** | **Queue** | **lcore** | **Description** |
- | | | | |
- +==========+============+===========+================================================+
- | 0 | 0 | 0 | Map queue 0 from port 0 to lcore 0. |
- | | | | |
- +----------+------------+-----------+------------------------------------------------+
- | 0 | 1 | 2 | Map queue 1 from port 0 to lcore 2. |
- | | | | |
- +----------+------------+-----------+------------------------------------------------+
- | 1 | 0 | 1 | Map queue 0 from port 1 to lcore 1. |
- | | | | |
- +----------+------------+-----------+------------------------------------------------+
- | 1 | 1 | 3 | Map queue 1 from port 1 to lcore 3. |
- | | | | |
- +----------+------------+-----------+------------------------------------------------+
+ +----------+------------+-----------+-------------------------------------+
+ | **Port** | **Queue** | **lcore** | **Description** |
+ | | | | |
+ +==========+============+===========+=====================================+
+ | 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1. |
+ | | | | |
+ +----------+------------+-----------+-------------------------------------+
+ | 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2. |
+ | | | | |
+ +----------+------------+-----------+-------------------------------------+
* The --rule_ipv4 option specifies the reading of IPv4 rules sets from the ./ rule_ipv4.db file.
diff --git a/doc/guides/sample_app_ug/l3_forward_virtual.rst b/doc/guides/sample_app_ug/l3_forward_virtual.rst
index fa04722..5f9d894 100644
--- a/doc/guides/sample_app_ug/l3_forward_virtual.rst
+++ b/doc/guides/sample_app_ug/l3_forward_virtual.rst
@@ -110,40 +110,33 @@ where,
* --no-numa: optional, disables numa awareness
-For example, consider a dual processor socket platform where cores 0,2,4,6, 8, and 10 appear on socket 0,
-while cores 1,3,5,7,9, and 11 appear on socket 1.
-Let's say that the programmer wants to use memory from both NUMA nodes,
-the platform has only two ports and the programmer wants to use one core from each processor socket to do the packet processing
-since only one Rx/Tx queue pair can be used in virtualization mode.
+For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0,
+while cores 8-15 and 24-31 appear on socket 1.
-To enable L3 forwarding between two ports, using one core from each processor,
-while also taking advantage of local memory accesses by optimizing around NUMA,
-the programmer can pin to the appropriate cores and allocate memory from the appropriate NUMA node.
-This is achieved using the following command:
+To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
+(which are in the same socket too), use the following command:
.. code-block:: console
- ./build/l3fwd-vf -c 0x03 -n 3 -- -p 0x3 --config="(0,0,0),(1,0,1)"
+ ./build/l3fwd-vf -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)"
In this command:
-* The -c option enables cores 0 and 1
+* The -l option enables cores 1 and 2
* The -p option enables ports 0 and 1
* The --config option enables one queue on each port and maps each (port,queue) pair to a specific core.
- Logic to enable multiple RX queues using RSS and to allocate memory from the correct NUMA nodes
- is included in the application and is done transparently.
The following table shows the mapping in this example:
+----------+-----------+-----------+------------------------------------+
| **Port** | **Queue** | **lcore** | **Description** |
| | | | |
+==========+===========+===========+====================================+
- | 0 | 0 | 0 | Map queue 0 from port 0 to lcore 0 |
+ | 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1 |
| | | | |
+----------+-----------+-----------+------------------------------------+
- | 1 | 1 | 1 | Map queue 0 from port 1 to lcore 1 |
+ | 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2 |
| | | | |
+----------+-----------+-----------+------------------------------------+
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] nfp: extend speed capabilities advertised
From: Alejandro Lucero @ 2016-12-19 16:18 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <3dd84942-5c7b-5f3f-2760-a71f97dfcd6a@intel.com>
On Mon, Dec 19, 2016 at 3:05 PM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> On 12/19/2016 3:02 PM, Alejandro Lucero wrote:
> >
> >
> > On Mon, Dec 19, 2016 at 2:36 PM, Ferruh Yigit <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>> wrote:
> >
> > Hi Alejandro,
> >
> >
> > Hi,
> >
> >
> > On 12/19/2016 12:05 PM, Alejandro Lucero wrote:
> > > NFP supports more speeds than just 40 and 100GB, which were
> > > what was advertised before.
> > >
> > > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com
> <mailto:alejandro.lucero@netronome.com>>
> > > ---
> > > drivers/net/nfp/nfp_net.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
> > > index 27afbfd..77015c4 100644
> > > --- a/drivers/net/nfp/nfp_net.c
> > > +++ b/drivers/net/nfp/nfp_net.c
> > > @@ -1077,7 +1077,9 @@ static void nfp_net_read_mac(struct
> nfp_net_hw *hw)
> > > dev_info->reta_size = NFP_NET_CFG_RSS_ITBL_SZ;
> > > dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
> > >
> > > - dev_info->speed_capa = ETH_LINK_SPEED_40G |
> ETH_LINK_SPEED_100G;
> > > + dev_info->speed_capa = ETH_SPEED_NUM_1G | ETH_LINK_SPEED_10G
> |
> > > + ETH_SPEED_NUM_25G | ETH_SPEED_NUM_40G
> |
> > > + ETH_SPEED_NUM_50G |
> ETH_LINK_SPEED_100G;
> >
> > Does all devices driver by this driver supports all these speeds?
> >
> > I am aware of at least one exception to this, from previous patch
> [1],
> > should we take that into account?
> >
> >
> > So we have different NFP devices and different firmwares.
> > NFP by design support all those speeds, but the PMD relies on the
> > firmware for being able to know which is the current configured speed
> > after link negotiation. PMD development was done with a specific
> > firmware, and I was told to just report such speed by default. Last
> > firmware versions give that speed info, but old firmware versions do not.
> >
> > So, all devices support such a speed range, indeed PMD works with any of
> > them, but reported speed is always 40G with old firmware. This is a
> > firmware limitation but we have to support old and new firmware.
>
> But this information to the application will be wrong for some (old) FW.
> What do you think checking the FW version here and report capability
> based on what FW supports?
>
>
The driver advertises the right speed range supported. The problem is with
the report about the current link speed configured.
Maybe, is the right thing to do here to not report the current link speed
because the driver really does not know about it?
If you agree with this, I'm afraid the just accepted patch about the link
report needs to be modified.
> >
> >
> >
> > Also other than that exception, can you please confirm all other
> devices
> > support all above speeds?
> >
> > [1]
> > + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
> > + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
> > + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
> > + link.link_speed = ETH_SPEED_NUM_40G;
> >
> >
> > > }
> > >
> > > static const uint32_t *
> > >
> >
> >
>
>
^ permalink raw reply
* Re: [PATCHv2 01/34] lib/ether: add rte_device in rte_eth_dev
From: Stephen Hemminger @ 2016-12-19 16:16 UTC (permalink / raw)
To: Hemant Agrawal
Cc: dev, thomas.monjalon, bruce.richardson, shreyansh.jain,
john.mcnamara, ferruh.yigit, jerin.jacob
In-Reply-To: <1482180853-18823-2-git-send-email-hemant.agrawal@nxp.com>
On Tue, 20 Dec 2016 02:23:40 +0530
Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> ---
> lib/librte_ether/rte_ethdev.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 9678179..0b601e9 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1626,6 +1626,7 @@ 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. */
> struct rte_eth_dev_data *data; /**< Pointer to device data */
> + struct rte_device *device;
> const struct eth_driver *driver;/**< Driver for this device */
> const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
> struct rte_pci_device *pci_dev; /**< PCI info. supplied by probing */
NAK
I would rather that rte_pci_device be eliminated from rte_eth_dev_data and
replace by more generic rte_device. I am working on a patch set to do this,
it is not fundamentally hard.
^ permalink raw reply
* Re: [PATCH] gitignore: ignore top level build/ directory
From: Bruce Richardson @ 2016-12-19 16:14 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Baruch Siach, Ferruh Yigit, dev
In-Reply-To: <1984848.mjZxypNVZ9@xps13>
On Mon, Dec 19, 2016 at 03:05:20PM +0100, Thomas Monjalon wrote:
> 2016-12-13 12:02, Ferruh Yigit:
> > On 12/13/2016 11:48 AM, Baruch Siach wrote:
> > > RTE_OUTPUT defaults to build/.
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> >
> > There is a similar patch:
> > http://dpdk.org/dev/patchwork/patch/11637/
> >
> > If you want you can review/comment that one too.
>
> Yes, sorry I've never commented above patch.
>
> I do not like filling .gitignore because I prefer
> seeing what is built or copied or whatever with "git status".
> What is really the benefit of .gitignore?
I take the opposite view. I only like to see files that I actually care
about in the git status. Any build artifacts should be ignored by git as
they are not files that it ever should track. That way doing a build
does not change the status of the repo as git sees it.
/Bruce
^ permalink raw reply
* [PATCH] nfp: avoid modulo operations for handling ring wrapping
From: Alejandro Lucero @ 2016-12-19 16:13 UTC (permalink / raw)
To: dev
Having those modulo operations implies costly instructions execution,
what can be avoided with conditionals and unlikely clauses.
This change makes the software ring read and write indexes to be now
always within the ring size which has to be handled properly. The main
problem is when write pointer wraps and being less than the read pointer.
This happened before, but just with indexes type size (uint32_t) wrapping,
and in that case the processor does the right thing no requiring special
hanling by software.
This work has also led to discovering redundant pointers in the driver,
which have been removed.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
drivers/net/nfp/nfp_net.c | 66 +++++++++++++++++++++----------------------
drivers/net/nfp/nfp_net_pmd.h | 5 +---
2 files changed, 33 insertions(+), 38 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index be0fefa..0e6bf4c 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -308,7 +308,6 @@ enum nfp_qcp_ptr {
nfp_net_reset_rx_queue(struct nfp_net_rxq *rxq)
{
nfp_net_rx_queue_release_mbufs(rxq);
- rxq->wr_p = 0;
rxq->rd_p = 0;
rxq->nb_rx_hold = 0;
}
@@ -347,8 +346,6 @@ enum nfp_qcp_ptr {
nfp_net_tx_queue_release_mbufs(txq);
txq->wr_p = 0;
txq->rd_p = 0;
- txq->tail = 0;
- txq->qcp_rd_p = 0;
}
static int
@@ -1114,8 +1111,7 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
return 0;
}
- idx = rxq->rd_p % rxq->rx_count;
- rxds = &rxq->rxds[idx];
+ idx = rxq->rd_p;
count = 0;
@@ -1414,8 +1410,6 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
rxd->fld.dma_addr_lo = dma_addr & 0xffffffff;
rxe[i].mbuf = mbuf;
PMD_RX_LOG(DEBUG, "[%d]: %" PRIx64 "\n", i, dma_addr);
-
- rxq->wr_p++;
}
/* Make sure all writes are flushed before telling the hardware */
@@ -1499,7 +1493,6 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
}
txq->tx_count = nb_desc;
- txq->tail = 0;
txq->tx_free_thresh = tx_free_thresh;
txq->tx_pthresh = tx_conf->tx_thresh.pthresh;
txq->tx_hthresh = tx_conf->tx_thresh.hthresh;
@@ -1691,7 +1684,6 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
struct nfp_net_hw *hw;
struct rte_mbuf *mb;
struct rte_mbuf *new_mb;
- int idx;
uint16_t nb_hold;
uint64_t dma_addr;
int avail;
@@ -1711,9 +1703,7 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
nb_hold = 0;
while (avail < nb_pkts) {
- idx = rxq->rd_p % rxq->rx_count;
-
- rxb = &rxq->rxbufs[idx];
+ rxb = &rxq->rxbufs[rxq->rd_p];
if (unlikely(rxb == NULL)) {
RTE_LOG_DP(ERR, PMD, "rxb does not exist!\n");
break;
@@ -1725,7 +1715,7 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
*/
rte_rmb();
- rxds = &rxq->rxds[idx];
+ rxds = &rxq->rxds[rxq->rd_p];
if ((rxds->rxd.meta_len_dd & PCIE_DESC_RX_DD) == 0)
break;
@@ -1813,6 +1803,8 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
rxds->fld.dma_addr_lo = dma_addr & 0xffffffff;
rxq->rd_p++;
+ if (unlikely(rxq->rd_p == rxq->rx_count)) /* wrapping?*/
+ rxq->rd_p = 0;
}
if (nb_hold == 0)
@@ -1858,33 +1850,40 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
/* Work out how many packets have been sent */
qcp_rd_p = nfp_qcp_read(txq->qcp_q, NFP_QCP_READ_PTR);
- if (qcp_rd_p == txq->qcp_rd_p) {
+ if (qcp_rd_p == txq->rd_p) {
PMD_TX_LOG(DEBUG, "queue %u: It seems harrier is not sending "
"packets (%u, %u)\n", txq->qidx,
- qcp_rd_p, txq->qcp_rd_p);
+ qcp_rd_p, txq->rd_p);
return 0;
}
- if (qcp_rd_p > txq->qcp_rd_p)
- todo = qcp_rd_p - txq->qcp_rd_p;
+ if (qcp_rd_p > txq->rd_p)
+ todo = qcp_rd_p - txq->rd_p;
else
- todo = qcp_rd_p + txq->tx_count - txq->qcp_rd_p;
+ todo = qcp_rd_p + txq->tx_count - txq->rd_p;
- PMD_TX_LOG(DEBUG, "qcp_rd_p %u, txq->qcp_rd_p: %u, qcp->rd_p: %u\n",
- qcp_rd_p, txq->qcp_rd_p, txq->rd_p);
+ PMD_TX_LOG(DEBUG, "qcp_rd_p %u, txq->rd_p: %u, qcp->rd_p: %u\n",
+ qcp_rd_p, txq->rd_p, txq->rd_p);
if (todo == 0)
return todo;
- txq->qcp_rd_p += todo;
- txq->qcp_rd_p %= txq->tx_count;
txq->rd_p += todo;
+ if (unlikely(txq->rd_p >= txq->tx_count))
+ txq->rd_p -= txq->tx_count;
return todo;
}
/* Leaving always free descriptors for avoiding wrapping confusion */
-#define NFP_FREE_TX_DESC(t) (t->tx_count - (t->wr_p - t->rd_p) - 8)
+static inline
+uint32_t nfp_free_tx_desc(struct nfp_net_txq *txq)
+{
+ if (txq->wr_p >= txq->rd_p)
+ return txq->tx_count - (txq->wr_p - txq->rd_p) - 8;
+ else
+ return txq->rd_p - txq->wr_p - 8;
+}
/*
* nfp_net_txq_full - Check if the TX queue free descriptors
@@ -1895,9 +1894,9 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
* This function uses the host copy* of read/write pointers
*/
static inline
-int nfp_net_txq_full(struct nfp_net_txq *txq)
+uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
{
- return NFP_FREE_TX_DESC(txq) < txq->tx_free_thresh;
+ return (nfp_free_tx_desc(txq) < txq->tx_free_thresh);
}
static uint16_t
@@ -1915,15 +1914,15 @@ int nfp_net_txq_full(struct nfp_net_txq *txq)
txq = tx_queue;
hw = txq->hw;
- txds = &txq->txds[txq->tail];
+ txds = &txq->txds[txq->wr_p];
PMD_TX_LOG(DEBUG, "working for queue %u at pos %d and %u packets\n",
- txq->qidx, txq->tail, nb_pkts);
+ txq->qidx, txq->wr_p, nb_pkts);
- if ((NFP_FREE_TX_DESC(txq) < nb_pkts) || (nfp_net_txq_full(txq)))
+ if ((nfp_free_tx_desc(txq) < nb_pkts) || (nfp_net_txq_full(txq)))
nfp_net_tx_free_bufs(txq);
- free_descs = (uint16_t)NFP_FREE_TX_DESC(txq);
+ free_descs = (uint16_t)nfp_free_tx_desc(txq);
if (unlikely(free_descs == 0))
return 0;
@@ -1936,7 +1935,7 @@ int nfp_net_txq_full(struct nfp_net_txq *txq)
/* Sending packets */
while ((i < nb_pkts) && free_descs) {
/* Grabbing the mbuf linked to the current descriptor */
- lmbuf = &txq->txbufs[txq->tail].mbuf;
+ lmbuf = &txq->txbufs[txq->wr_p].mbuf;
/* Warming the cache for releasing the mbuf later on */
RTE_MBUF_PREFETCH_TO_FREE(*lmbuf);
@@ -1998,9 +1997,8 @@ int nfp_net_txq_full(struct nfp_net_txq *txq)
free_descs--;
txq->wr_p++;
- txq->tail++;
- if (unlikely(txq->tail == txq->tx_count)) /* wrapping?*/
- txq->tail = 0;
+ if (unlikely(txq->wr_p == txq->tx_count)) /* wrapping?*/
+ txq->wr_p = 0;
pkt_size -= dma_size;
if (!pkt_size) {
@@ -2011,7 +2009,7 @@ int nfp_net_txq_full(struct nfp_net_txq *txq)
pkt = pkt->next;
}
/* Referencing next free TX descriptor */
- txds = &txq->txds[txq->tail];
+ txds = &txq->txds[txq->wr_p];
issued_descs++;
}
i++;
diff --git a/drivers/net/nfp/nfp_net_pmd.h b/drivers/net/nfp/nfp_net_pmd.h
index dc70d57..4df2275 100644
--- a/drivers/net/nfp/nfp_net_pmd.h
+++ b/drivers/net/nfp/nfp_net_pmd.h
@@ -216,12 +216,10 @@ struct nfp_net_txq {
uint32_t wr_p;
uint32_t rd_p;
- uint32_t qcp_rd_p;
uint32_t tx_count;
uint32_t tx_free_thresh;
- uint32_t tail;
/*
* For each descriptor keep a reference to the mbuff and
@@ -240,7 +238,7 @@ struct nfp_net_txq {
struct nfp_net_tx_desc *txds;
/*
- * At this point 56 bytes have been used for all the fields in the
+ * At this point 48 bytes have been used for all the fields in the
* TX critical path. We have room for 8 bytes and still all placed
* in a cache line. We are not using the threshold values below nor
* the txq_flags but if we need to, we can add the most used in the
@@ -326,7 +324,6 @@ struct nfp_net_rxq {
* freelist descriptors and @rd_p is where the driver start
* reading descriptors for newly arrive packets from.
*/
- uint32_t wr_p;
uint32_t rd_p;
/*
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 2/6] eventdev: define southbound driver interface
From: Bruce Richardson @ 2016-12-19 15:50 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, hemant.agrawal, gage.eads, harry.van.haaren
In-Reply-To: <1482070895-32491-3-git-send-email-jerin.jacob@caviumnetworks.com>
On Sun, Dec 18, 2016 at 07:51:31PM +0530, Jerin Jacob wrote:
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_eventdev/rte_eventdev.h | 38 +++++
> lib/librte_eventdev/rte_eventdev_pmd.h | 291 +++++++++++++++++++++++++++++++++
> 2 files changed, 329 insertions(+)
> create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h
>
<snip>
> +
> +/**
> + * Release resources allocated by given event queue.
> + *
> + * @param queue_id
> + * Event queue index
> + *
> + */
> +typedef void (*eventdev_queue_release_t)(uint8_t queue_id);
> +
Missing an eventdev pointer here too, otherwise you can't use the queue
index to find the queue.
/Bruce
^ permalink raw reply
* Re: [PATCH 22/32] net/dpaa2: configure mac address at init
From: Hemant Agrawal @ 2016-12-19 15:31 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <c41f7e86-d485-6a9a-0aa1-2b2406c32861@intel.com>
On 12/7/2016 1:20 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> drivers/net/dpaa2/base/dpaa2_hw_dpni.h | 3 +++
>> drivers/net/dpaa2/dpaa2_ethdev.c | 26 ++++++++++++++++++++++++++
>> 2 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpni.h b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> index c109396..70d52b6 100644
>> --- a/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> @@ -63,7 +63,10 @@ struct dpaa2_dev_priv {
>> void *rx_vq[MAX_RX_QUEUES];
>> void *tx_vq[MAX_TX_QUEUES];
>>
>> + uint32_t options;
>> uint16_t num_dist_per_tc[MAX_TCS];
>> + uint8_t max_mac_filters;
>> + uint8_t max_vlan_filters;
>> uint8_t num_tc;
>> uint8_t flags; /*dpaa2 config flags */
>> };
>> diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
>> index 094296a..65c3384 100644
>> --- a/drivers/net/dpaa2/dpaa2_ethdev.c
>> +++ b/drivers/net/dpaa2/dpaa2_ethdev.c
>> @@ -64,8 +64,12 @@
>> dev_info->driver_name = drivername;
>> dev_info->if_index = priv->hw_id;
>>
>> + dev_info->max_mac_addrs = priv->max_mac_filters;
>> dev_info->max_rx_queues = (uint16_t)priv->nb_rx_queues;
>> dev_info->max_tx_queues = (uint16_t)priv->nb_tx_queues;
>> + dev_info->speed_capa = ETH_LINK_SPEED_1G |
>> + ETH_LINK_SPEED_2_5G |
>> + ETH_LINK_SPEED_10G;
>
> Patch does a little more than what it says, this can be added to prev
> patch that introduces dpaa2_dev_info_get()
>
I have fixed it.
>> }
>>
>> static int
>> @@ -444,6 +448,9 @@
>
> Overall this makes harder to review, there is no function name provided
> int the patch, this is same for all patchset. There was a .gitattributes
> patch in the mail list for this, can you please get it before sending
> next revision of patches.
I have tried to take care of it in v2. Please check now.
>>
>> priv->hw = dpni_dev;
>> priv->hw_id = hw_id;
>> + priv->options = attr.options;
>> + priv->max_mac_filters = attr.mac_filter_entries;
>> + priv->max_vlan_filters = attr.vlan_filter_entries;
>> priv->flags = 0;
>>
>> ret = dpaa2_alloc_rx_tx_queues(eth_dev);
>> @@ -452,6 +459,25 @@
>> return -ret;
>> }
>>
>> + /* Allocate memory for storing MAC addresses */
>> + eth_dev->data->mac_addrs = rte_zmalloc("dpni",
>> + ETHER_ADDR_LEN * attr.mac_filter_entries, 0);
>> + if (eth_dev->data->mac_addrs == NULL) {
>> + PMD_INIT_LOG(ERR, "Failed to allocate %d bytes needed to "
>> + "store MAC addresses",
>> + ETHER_ADDR_LEN * attr.mac_filter_entries);
>> + return -ENOMEM;
>> + }
>> +
>> + ret = dpni_get_primary_mac_addr(dpni_dev, CMD_PRI_LOW,
>> + priv->token,
>> + (uint8_t *)(eth_dev->data->mac_addrs[0].addr_bytes));
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "DPNI get mac address failed:"
>> + " Error Code = %d\n", ret);
>> + return -ret;
>> + }
>> +
>> eth_dev->dev_ops = &dpaa2_ethdev_ops;
>> return 0;
>> }
>>
>
>
^ permalink raw reply
* Re: [PATCH 20/32] net/dpaa2: add queue configuration support
From: Hemant Agrawal @ 2016-12-19 15:30 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <4a688759-269f-3556-e32c-df14ccfa3b9a@intel.com>
On 12/7/2016 1:19 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> doc/guides/nics/features/dpaa2.ini | 1 +
>> drivers/net/dpaa2/base/dpaa2_hw_dpni.h | 14 +-
>> drivers/net/dpaa2/base/dpaa2_hw_pvt.h | 21 +++
>> drivers/net/dpaa2/dpaa2_ethdev.c | 254 ++++++++++++++++++++++++++++++++-
>> 4 files changed, 288 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/guides/nics/features/dpaa2.ini b/doc/guides/nics/features/dpaa2.ini
>> index b176208..0b59725 100644
>> --- a/doc/guides/nics/features/dpaa2.ini
>> +++ b/doc/guides/nics/features/dpaa2.ini
>> @@ -4,6 +4,7 @@
>> ; Refer to default.ini for the full list of available PMD features.
>> ;
>> [Features]
>> +Queue start/stop = Y
>> Linux VFIO = Y
>> ARMv8 = Y
>> Usage doc = Y
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpni.h b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> index 1b655e4..197fd28 100644
>> --- a/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> @@ -36,15 +36,27 @@
>>
>> #include <fsl_dpni.h>
>> #include <fsl_mc_sys.h>
>> +
>> +#define MAX_RX_QUEUES 16
>> +#define MAX_TX_QUEUES 16
>> +
>> +/*default tc to be used for ,congestion, distribution etc configuration. */
>> +#define DPAA2_DEF_TC 0
>> +
>> /*! Global MCP list */
>> extern void *(*mcp_ptr_list);
>>
>> -
>> struct dpaa2_dev_priv {
>> void *hw;
>> int32_t hw_id;
>> + int32_t qdid;
>> uint16_t token;
>> + uint8_t nb_tx_queues;
>> + uint8_t nb_rx_queues;
>> + void *rx_vq[MAX_RX_QUEUES];
>> + void *tx_vq[MAX_TX_QUEUES];
>>
>> + uint8_t num_tc;
>> uint8_t flags; /*dpaa2 config flags */
>> };
>> #endif /* _DPAA2_DPNI_H_ */
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_pvt.h b/drivers/net/dpaa2/base/dpaa2_hw_pvt.h
>> index 5038209..867611f 100644
>> --- a/drivers/net/dpaa2/base/dpaa2_hw_pvt.h
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_pvt.h
>> @@ -37,9 +37,12 @@
>> #include <fsl_mc_sys.h>
>> #include <fsl_qbman_portal.h>
>>
>> +#define DPAA2_DQRR_RING_SIZE 16
>> + /** <Maximum number of slots available in RX ring*/
>>
>> #define MC_PORTAL_INDEX 0
>> #define NUM_DPIO_REGIONS 2
>> +#define NUM_DQS_PER_QUEUE 2
>>
>> #define MEMPOOL_F_HW_PKT_POOL 0x8000 /**< mpool flag to check offloaded pool */
>>
>> @@ -70,6 +73,24 @@ struct dpaa2_dpio_dev {
>> int32_t hw_id; /**< An unique ID of this DPIO device instance */
>> };
>>
>> +struct queue_storage_info_t {
>> + struct qbman_result *dq_storage[NUM_DQS_PER_QUEUE];
>> +};
>> +
>> +struct dpaa2_queue {
>> + struct rte_mempool *mb_pool; /**< mbuf pool to populate RX ring. */
>> + void *dev;
>> + int32_t eventfd; /*!< Event Fd of this queue */
>> + uint32_t fqid; /*!< Unique ID of this queue */
>> + uint8_t tc_index; /*!< traffic class identifier */
>> + uint16_t flow_id; /*!< To be used by DPAA2 frmework */
>> + uint64_t rx_pkts;
>> + uint64_t tx_pkts;
>> + uint64_t err_pkts;
>> + struct queue_storage_info_t *q_storage;
>> +};
>> +
>> /*! Global MCP list */
>> extern void *(*mcp_ptr_list);
>> +
>> #endif
>> diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
>> index daf59c1..45c3f8f 100644
>> --- a/drivers/net/dpaa2/dpaa2_ethdev.c
>> +++ b/drivers/net/dpaa2/dpaa2_ethdev.c
>> @@ -46,10 +46,94 @@
>> #include <rte_dpaa2.h>
>>
>> #include <dpaa2_logs.h>
>> +#include <base/dpaa2_hw_pvt.h>
>> #include <base/dpaa2_hw_dpni.h>
>> /* DPDK Interfaces */
>> #include <dpaa2_ethdev.h>
>>
>> +/* Name of the DPAA2 Net PMD */
>> +static const char *drivername = "DPNI PMD";
>> +
>> +static void
>> +dpaa2_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + dev_info->driver_name = drivername;
>
> Please check patches
> http://dpdk.org/dev/patchwork/patch/17170/
> http://dpdk.org/dev/patchwork/patch/17171/
>
ok. I have taken care of it.
>> + dev_info->if_index = priv->hw_id;
>> +
>> + dev_info->max_rx_queues = (uint16_t)priv->nb_rx_queues;
>> + dev_info->max_tx_queues = (uint16_t)priv->nb_tx_queues;
>> +}
>> +
>> +static int
>> +dpaa2_alloc_rx_tx_queues(struct rte_eth_dev *dev)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> + uint16_t dist_idx;
>> + uint32_t vq_id;
>> + struct dpaa2_queue *mc_q, *mcq;
>> + uint32_t tot_queues;
>> + int i;
>> + struct dpaa2_queue *dpaa2_q;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + tot_queues = priv->nb_rx_queues + priv->nb_tx_queues;
>> + mc_q = rte_malloc(NULL, sizeof(struct dpaa2_queue) * tot_queues,
>> + RTE_CACHE_LINE_SIZE);
>> + if (!mc_q) {
>> + PMD_INIT_LOG(ERR, "malloc failed for rx/tx queues\n");
>> + return -1;
>> + }
>> +
>> + for (i = 0; i < priv->nb_rx_queues; i++) {
>> + mc_q->dev = dev;
>> + priv->rx_vq[i] = mc_q++;
>> + dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[i];
>> + dpaa2_q->q_storage = rte_malloc("dq_storage",
>> + sizeof(struct queue_storage_info_t),
>> + RTE_CACHE_LINE_SIZE);
>> + if (!dpaa2_q->q_storage)
>> + goto fail;
>> +
>> + memset(dpaa2_q->q_storage, 0,
>> + sizeof(struct queue_storage_info_t));
>> + dpaa2_q->q_storage->dq_storage[0] = rte_malloc(NULL,
>> + DPAA2_DQRR_RING_SIZE * sizeof(struct qbman_result),
>> + RTE_CACHE_LINE_SIZE);
>> + }
>> +
>> + for (i = 0; i < priv->nb_tx_queues; i++) {
>> + mc_q->dev = dev;
>> + mc_q->flow_id = DPNI_NEW_FLOW_ID;
>> + priv->tx_vq[i] = mc_q++;
>> + }
>> +
>> + vq_id = 0;
>> + for (dist_idx = 0; dist_idx < priv->nb_rx_queues; dist_idx++) {
>> + mcq = (struct dpaa2_queue *)priv->rx_vq[vq_id];
>> + mcq->tc_index = DPAA2_DEF_TC;
>> + mcq->flow_id = dist_idx;
>> + vq_id++;
>> + }
>> +
>> + return 0;
>> +fail:
>> + i -= 1;
>> + mc_q = priv->rx_vq[0];
>> + while (i >= 0) {
>> + dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[i];
>> + rte_free(dpaa2_q->q_storage->dq_storage[0]);
>> + rte_free(dpaa2_q->q_storage);
>> + priv->rx_vq[i--] = NULL;
>> + }
>> + rte_free(mc_q);
>> + return -1;
>> +}
>> +
>> static int
>> dpaa2_eth_dev_configure(struct rte_eth_dev *dev)
>> {
>> @@ -69,15 +153,134 @@
>> return 0;
>> }
>>
>> +/* Function to setup RX flow information. It contains traffic class ID,
>> + * flow ID, destination configuration etc.
>> + */
>> static int
>> -dpaa2_dev_start(struct rte_eth_dev *dev)
>> +dpaa2_dev_rx_queue_setup(struct rte_eth_dev *dev,
>> + uint16_t rx_queue_id,
>> + uint16_t nb_rx_desc __rte_unused,
>> + unsigned int socket_id __rte_unused,
>> + const struct rte_eth_rxconf *rx_conf __rte_unused,
>> + struct rte_mempool *mb_pool)
>> {
>> struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
>> + struct dpaa2_queue *dpaa2_q;
>> + struct dpni_queue cfg;
>> + uint8_t options = 0;
>> + uint8_t flow_id;
>> + int ret;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + PMD_INIT_LOG(DEBUG, "dev =%p, queue =%d, pool = %p, conf =%p",
>> + dev, rx_queue_id, mb_pool, rx_conf);
>> +
>> + dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[rx_queue_id];
>> + dpaa2_q->mb_pool = mb_pool; /**< mbuf pool to populate RX ring. */
>> +
>> + /*Get the tc id and flow id from given VQ id*/
>> + flow_id = rx_queue_id;
>> + memset(&cfg, 0, sizeof(struct dpni_queue));
>> +
>> + options = options | DPNI_QUEUE_OPT_USER_CTX;
>> + cfg.user_context = (uint64_t)(dpaa2_q);
>> +
>> + ret = dpni_set_queue(dpni, CMD_PRI_LOW, priv->token, DPNI_QUEUE_RX,
>> + dpaa2_q->tc_index, flow_id, options, &cfg);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Error in setting the rx flow: = %d\n", ret);
>> + return -1;
>> + }
>> +
>> + dev->data->rx_queues[rx_queue_id] = dpaa2_q;
>> + return 0;
>> +}
>> +
>> +static int
>> +dpaa2_dev_tx_queue_setup(struct rte_eth_dev *dev,
>> + uint16_t tx_queue_id,
>> + uint16_t nb_tx_desc __rte_unused,
>> + unsigned int socket_id __rte_unused,
>> + const struct rte_eth_txconf *tx_conf __rte_unused)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> + struct dpaa2_queue *dpaa2_q = (struct dpaa2_queue *)
>> + priv->tx_vq[tx_queue_id];
>> + struct fsl_mc_io *dpni = priv->hw;
>> + struct dpni_queue tx_conf_cfg;
>> + struct dpni_queue tx_flow_cfg;
>> + uint8_t options = 0, flow_id;
>> + uint32_t tc_id;
>> int ret;
>>
>> PMD_INIT_FUNC_TRACE();
>>
>> + /* Return if queue already configured */
>> + if (dpaa2_q->flow_id != DPNI_NEW_FLOW_ID)
>> + return 0;
>> +
>> + memset(&tx_conf_cfg, 0, sizeof(struct dpni_queue));
>> + memset(&tx_flow_cfg, 0, sizeof(struct dpni_queue));
>> +
>> + tc_id = 0;
>> + flow_id = tx_queue_id;
>> +
>> + ret = dpni_set_queue(dpni, CMD_PRI_LOW, priv->token, DPNI_QUEUE_TX,
>> + tc_id, flow_id, options, &tx_flow_cfg);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Error in setting the tx flow: "
>> + "tc_id=%d, flow =%d ErrorCode = %x\n",
>> + tc_id, flow_id, -ret);
>> + return -1;
>> + }
>> +
>> + dpaa2_q->flow_id = flow_id;
>> +
>> + if (tx_queue_id == 0) {
>> + /*Set tx-conf and error configuration*/
>> + ret = dpni_set_tx_confirmation_mode(dpni, CMD_PRI_LOW,
>> + priv->token,
>> + DPNI_CONF_DISABLE);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Error in set tx conf mode settings"
>> + " ErrorCode = %x", ret);
>> + return -1;
>> + }
>> + }
>> + dpaa2_q->tc_index = tc_id;
>> +
>> + dev->data->tx_queues[tx_queue_id] = dpaa2_q;
>> + return 0;
>> +}
>> +
>> +static void
>> +dpaa2_dev_rx_queue_release(void *q __rte_unused)
>> +{
>> + PMD_INIT_FUNC_TRACE();
>> +}
>> +
>> +static void
>> +dpaa2_dev_tx_queue_release(void *q __rte_unused)
>> +{
>> + PMD_INIT_FUNC_TRACE();
>> +}
>> +
>> +static int
>> +dpaa2_dev_start(struct rte_eth_dev *dev)
>> +{
>> + struct rte_eth_dev_data *data = dev->data;
>> + struct dpaa2_dev_priv *priv = data->dev_private;
>> + struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
>> + struct dpni_queue cfg;
>> + uint16_t qdid;
>> + struct dpni_queue_id qid;
>> + struct dpaa2_queue *dpaa2_q;
>> + int ret, i;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> ret = dpni_enable(dpni, CMD_PRI_LOW, priv->token);
>> if (ret) {
>> PMD_INIT_LOG(ERR, "Failure %d in enabling dpni %d device\n",
>> @@ -85,6 +288,27 @@
>> return ret;
>> }
>>
>> + ret = dpni_get_qdid(dpni, CMD_PRI_LOW, priv->token,
>> + DPNI_QUEUE_TX, &qdid);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Error to get qdid:ErrorCode = %d\n", ret);
>> + return ret;
>> + }
>> + priv->qdid = qdid;
>> +
>> + for (i = 0; i < data->nb_rx_queues; i++) {
>> + dpaa2_q = (struct dpaa2_queue *)data->rx_queues[i];
>> + ret = dpni_get_queue(dpni, CMD_PRI_LOW, priv->token,
>> + DPNI_QUEUE_RX, dpaa2_q->tc_index,
>> + dpaa2_q->flow_id, &cfg, &qid);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Error to get flow "
>> + "information Error code = %d\n", ret);
>> + return ret;
>> + }
>> + dpaa2_q->fqid = qid.fqid;
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -132,6 +356,11 @@
>> .dev_start = dpaa2_dev_start,
>> .dev_stop = dpaa2_dev_stop,
>> .dev_close = dpaa2_dev_close,
>> + .dev_infos_get = dpaa2_dev_info_get,
>> + .rx_queue_setup = dpaa2_dev_rx_queue_setup,
>> + .rx_queue_release = dpaa2_dev_rx_queue_release,
>> + .tx_queue_setup = dpaa2_dev_tx_queue_setup,
>> + .tx_queue_release = dpaa2_dev_tx_queue_release,
>> };
>>
>> int
>> @@ -140,6 +369,7 @@
>> struct rte_device *dev = eth_dev->device;
>> struct rte_dpaa2_device *dpaa2_dev;
>> struct fsl_mc_io *dpni_dev;
>> + struct dpni_attr attr;
>> struct dpaa2_dev_priv *priv = eth_dev->data->dev_private;
>> int ret, hw_id;
>>
>> @@ -175,8 +405,30 @@
>> return -1;
>> }
>>
>> + ret = dpni_get_attributes(dpni_dev, CMD_PRI_LOW, priv->token, &attr);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure in getting dpni@%d attribute, "
>> + " error code %d\n", hw_id, ret);
>> + return -1;
>> + }
>> +
>> + priv->num_tc = attr.num_tcs;
>> + priv->nb_rx_queues = attr.num_queues;
>> + priv->nb_tx_queues = attr.num_queues;
>> +
>> + eth_dev->data->nb_rx_queues = priv->nb_rx_queues;
>> + eth_dev->data->nb_tx_queues = priv->nb_tx_queues;
>> +
>> priv->hw = dpni_dev;
>> priv->hw_id = hw_id;
>> + priv->flags = 0;
>> +
>> + ret = dpaa2_alloc_rx_tx_queues(eth_dev);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "dpaa2_alloc_rx_tx_queuesFailed\n");
>> + return -ret;
>> + }
>> +
>> eth_dev->dev_ops = &dpaa2_ethdev_ops;
>> return 0;
>> }
>>
>
>
^ permalink raw reply
* Re: [PATCH 19/32] net/dpaa2: adding eth ops to dpaa2
From: Hemant Agrawal @ 2016-12-19 15:28 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <1b3c3956-d2d8-e6b4-b058-369dca9fa63a@intel.com>
On 12/7/2016 1:19 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> drivers/net/dpaa2/base/dpaa2_hw_dpni.h | 50 +++++++++++++
>> drivers/net/dpaa2/dpaa2_ethdev.c | 130 ++++++++++++++++++++++++++++++++-
>> 2 files changed, 179 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>>
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpni.h b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> new file mode 100644
>> index 0000000..1b655e4
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> @@ -0,0 +1,50 @@
>> +/*-
>> + * BSD LICENSE
>> + *
>> + * Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
>> + * Copyright (c) 2016 NXP. 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 Freescale Semiconductor, Inc 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.
>> + */
>> +
>> +#ifndef _DPAA2_HW_DPNI_H_
>> +#define _DPAA2_HW_DPNI_H_
>> +
>> +#include <fsl_dpni.h>
>> +#include <fsl_mc_sys.h>
>> +/*! Global MCP list */
>> +extern void *(*mcp_ptr_list);
>
> extern keyword not needed.
>
>> +
>> +
>> +struct dpaa2_dev_priv {
>
> Any reason this is not in dpaa2_ethdev.h but in a new header file, since
> this looks like ethernet device private data. Just asking.
>
I agree, I have taken care of it in v2.
>> + void *hw;
>> + int32_t hw_id;
>> + uint16_t token;
>> +
>> + uint8_t flags; /*dpaa2 config flags */
>> +};
>> +#endif /* _DPAA2_DPNI_H_ */
>> diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
>> index 17dfff6..daf59c1 100644
>> --- a/drivers/net/dpaa2/dpaa2_ethdev.c
>> +++ b/drivers/net/dpaa2/dpaa2_ethdev.c
>> @@ -43,12 +43,140 @@
>> #include <rte_kvargs.h>
>> #include <rte_dev.h>
>> #include <rte_ethdev.h>
>> +#include <rte_dpaa2.h>
>>
>> +#include <dpaa2_logs.h>
>> +#include <base/dpaa2_hw_dpni.h>
>> /* DPDK Interfaces */
>> #include <dpaa2_ethdev.h>
>>
>> +static int
>> +dpaa2_eth_dev_configure(struct rte_eth_dev *dev)
>> +{
>> + struct rte_eth_dev_data *data = dev->data;
>> + struct rte_eth_conf *eth_conf = &data->dev_conf;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + /* Check for correct configuration */
>> + if (eth_conf->rxmode.mq_mode != ETH_MQ_RX_RSS &&
>> + data->nb_rx_queues > 1) {
>> + PMD_INIT_LOG(ERR, "Distribution is not enabled, "
>> + "but Rx queues more than 1\n");
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int
>> +dpaa2_dev_start(struct rte_eth_dev *dev)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> + struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
>> + int ret;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + ret = dpni_enable(dpni, CMD_PRI_LOW, priv->token);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure %d in enabling dpni %d device\n",
>> + ret, priv->hw_id);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * This routine disables all traffic on the adapter by issuing a
>> + * global reset on the MAC.
>> + */
>> +static void
>> +dpaa2_dev_stop(struct rte_eth_dev *dev)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> + struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
>> + int ret;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + ret = dpni_disable(dpni, CMD_PRI_LOW, priv->token);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure (ret %d) in disabling dpni %d dev\n",
>> + ret, priv->hw_id);
>> + return;
>> + }
>> +}
>> +
>> +static void
>> +dpaa2_dev_close(struct rte_eth_dev *dev)
>> +{
>> + struct dpaa2_dev_priv *priv = dev->data->dev_private;
>> + struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
>> + int ret;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + /* Clean the device first */
>> + ret = dpni_reset(dpni, CMD_PRI_LOW, priv->token);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure cleaning dpni device with"
>> + " error code %d\n", ret);
>> + return;
>> + }
>> +}
>> +
>> +static struct eth_dev_ops dpaa2_ethdev_ops = {
>> + .dev_configure = dpaa2_eth_dev_configure,
>> + .dev_start = dpaa2_dev_start,
>> + .dev_stop = dpaa2_dev_stop,
>> + .dev_close = dpaa2_dev_close,
>> +};
>> +
>> int
>> -dpaa2_dev_init(struct rte_eth_dev *eth_dev __rte_unused)
>> +dpaa2_dev_init(struct rte_eth_dev *eth_dev)
>> {
>> + struct rte_device *dev = eth_dev->device;
>> + struct rte_dpaa2_device *dpaa2_dev;
>> + struct fsl_mc_io *dpni_dev;
>> + struct dpaa2_dev_priv *priv = eth_dev->data->dev_private;
>> + int ret, hw_id;
>> +
>> + PMD_INIT_FUNC_TRACE();
>> +
>> + /* For secondary processes, the primary has done all the work */
>> + if (rte_eal_process_type() != RTE_PROC_PRIMARY)
>> + return 0;
>> +
>> + dpaa2_dev = container_of(dev, struct rte_dpaa2_device, device);
>> +
>> + hw_id = dpaa2_dev->object_id;
>> +
>> + dpni_dev = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
>> + if (!dpni_dev) {
>> + PMD_INIT_LOG(ERR, "malloc failed for dpni device\n");
>> + return -1;
>> + }
>> +
>> + dpni_dev->regs = mcp_ptr_list[0];
>> + ret = dpni_open(dpni_dev, CMD_PRI_LOW, hw_id, &priv->token);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure in opening dpni@%d device with"
>> + " error code %d\n", hw_id, ret);
>> + return -1;
>> + }
>> +
>> + /* Clean the device first */
>> + ret = dpni_reset(dpni_dev, CMD_PRI_LOW, priv->token);
>> + if (ret) {
>> + PMD_INIT_LOG(ERR, "Failure cleaning dpni@%d device with"
>> + " error code %d\n", hw_id, ret);
>> + return -1;
>> + }
>
> Is rte_eth_copy_pci_info() equivalent something required here, to set
> some default values?
>
No, it is not required for the dpaa2 type devices. the common data is
being initialized in these function itself.
>> +
>> + priv->hw = dpni_dev;
>> + priv->hw_id = hw_id;
>> + eth_dev->dev_ops = &dpaa2_ethdev_ops;
>> return 0;
>> }
>>
>
>
^ permalink raw reply
* Re: [PATCH 15/32] net/dpaa2: dpio routine to affine to crypto threads
From: Hemant Agrawal @ 2016-12-19 15:25 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <c363a528-02a1-6e56-0eea-85598d5f0d40@intel.com>
On 12/7/2016 1:19 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> drivers/net/dpaa2/base/dpaa2_hw_dpio.c | 45 ++++++++++++++++++++++++++++++++++
>> drivers/net/dpaa2/base/dpaa2_hw_dpio.h | 3 +++
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpio.c b/drivers/net/dpaa2/base/dpaa2_hw_dpio.c
>> index 4a0a638..9c6eb96 100644
>> --- a/drivers/net/dpaa2/base/dpaa2_hw_dpio.c
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpio.c
>> @@ -275,6 +275,51 @@ static inline struct dpaa2_dpio_dev *dpaa2_get_qbman_swp(void)
>> }
>>
>> int
>> +dpaa2_affine_qbman_swp_sec(void)
>> +{
>> + unsigned lcore_id = rte_lcore_id();
>> + uint64_t tid = syscall(SYS_gettid);
>> +
>> + if (lcore_id == LCORE_ID_ANY)
>> + lcore_id = rte_get_master_lcore();
>> + /* if the core id is not supported */
>> + else if (lcore_id >= RTE_MAX_LCORE)
>> + return -1;
>> +
>> + if (dpaa2_io_portal[lcore_id].sec_dpio_dev) {
>> + PMD_DRV_LOG(INFO, "DPAA Portal=0x%x (%d) is being shared"
>> + " between thread %lu and current %lu",
>> + dpaa2_io_portal[lcore_id].sec_dpio_dev,
>> + dpaa2_io_portal[lcore_id].sec_dpio_dev->index,
>> + dpaa2_io_portal[lcore_id].sec_tid,
>> + tid);
>> + RTE_PER_LCORE(_dpaa2_io).sec_dpio_dev
>> + = dpaa2_io_portal[lcore_id].sec_dpio_dev;
>> + rte_atomic16_inc(&dpaa2_io_portal
>> + [lcore_id].sec_dpio_dev->ref_count);
>> + dpaa2_io_portal[lcore_id].sec_tid = tid;
>> +
>> + PMD_DRV_LOG(DEBUG, "Old Portal=0x%x (%d) affined thread - %lu",
>> + dpaa2_io_portal[lcore_id].sec_dpio_dev,
>> + dpaa2_io_portal[lcore_id].sec_dpio_dev->index,
>> + tid);
>> + return 0;
>> + }
>> +
>> + /* Populate the dpaa2_io_portal structure */
>> + dpaa2_io_portal[lcore_id].sec_dpio_dev = dpaa2_get_qbman_swp();
>> +
>> + if (dpaa2_io_portal[lcore_id].sec_dpio_dev) {
>> + RTE_PER_LCORE(_dpaa2_io).sec_dpio_dev
>> + = dpaa2_io_portal[lcore_id].sec_dpio_dev;
>> + dpaa2_io_portal[lcore_id].sec_tid = tid;
>> + return 0;
>> + } else {
>> + return -1;
>> + }
>> +}
>> +
>> +int
>> dpaa2_create_dpio_device(struct dpaa2_vfio_device *vdev,
>> struct vfio_device_info *obj_info,
>> int object_id)
>> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpio.h b/drivers/net/dpaa2/base/dpaa2_hw_dpio.h
>> index d90b900..8480ce3 100644
>> --- a/drivers/net/dpaa2/base/dpaa2_hw_dpio.h
>> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpio.h
>> @@ -57,6 +57,9 @@ struct dpaa2_io_portal_t {
>> /* Affine a DPIO portal to current processing thread */
>> int dpaa2_affine_qbman_swp(void);
>>
>> +/* Affine additional DPIO portal to current crypto processing thread */
>> +int dpaa2_affine_qbman_swp_sec(void);
>
> Why crypto related code in net driver base folder? Shouldn't these go to
> common folder?
>
I agree, dpio is now in common/dpaa2 folder in v2.
>> +
>> /* create dpio device */
>> int dpaa2_create_dpio_device(struct dpaa2_vfio_device *vdev,
>> struct vfio_device_info *obj_info,
>>
>
>
^ permalink raw reply
* Re: [PATCH 13/32] net/dpaa2: add debug log macros
From: Hemant Agrawal @ 2016-12-19 15:24 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <c7716cd5-df3b-bdb3-72a8-ebcf2adc35a2@intel.com>
On 12/7/2016 1:19 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> config/defconfig_arm64-dpaa2-linuxapp-gcc | 2 +
>> drivers/net/dpaa2/Makefile | 5 ++
>> drivers/net/dpaa2/dpaa2_logs.h | 77 +++++++++++++++++++++++++++++++
>> 3 files changed, 84 insertions(+)
>> create mode 100644 drivers/net/dpaa2/dpaa2_logs.h
>>
>> diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> index 00f207e..5ff884b 100644
>> --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> @@ -45,3 +45,5 @@ CONFIG_RTE_MAX_NUMA_NODES=1
>> # Compile software PMD backed by NXP DPAA2 files
>> #
>> CONFIG_RTE_LIBRTE_DPAA2_PMD=y
>> +CONFIG_RTE_LIBRTE_DPAA2_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_DPAA2_DEBUG_DRIVER=n
>> diff --git a/drivers/net/dpaa2/Makefile b/drivers/net/dpaa2/Makefile
>> index ab17143..3032708 100644
>> --- a/drivers/net/dpaa2/Makefile
>> +++ b/drivers/net/dpaa2/Makefile
>> @@ -35,8 +35,13 @@ include $(RTE_SDK)/mk/rte.vars.mk
>> #
>> LIB = librte_pmd_dpaa2.a
>>
>> +ifeq ($(CONFIG_RTE_LIBRTE_DPAA2_DEBUG_INIT),y)
>> +CFLAGS += -O0 -g
>> +CFLAGS += "-Wno-error"
>> +else
>> CFLAGS += -O3
>> CFLAGS += $(WERROR_FLAGS)
>> +endif
>>
>> CFLAGS += -I$(RTE_SDK)/drivers/net/dpaa2
>> CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/
>> diff --git a/drivers/net/dpaa2/dpaa2_logs.h b/drivers/net/dpaa2/dpaa2_logs.h
>> new file mode 100644
>> index 0000000..956a940
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/dpaa2_logs.h
>> @@ -0,0 +1,77 @@
>> +/*-
>> + * BSD LICENSE
>> + *
>> + * Copyright (c) 2015-2016 Freescale Semiconductor, Inc. All rights reserved.
>> + * Copyright (c) 2016 NXP. 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 Freescale Semiconductor, Inc 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.
>> + */
>> +
>> +#ifndef _DPAA2_LOGS_H_
>> +#define _DPAA2_LOGS_H_
>> +
>> +#define PMD_INIT_LOG(level, fmt, args...) \
>> + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ##args)
>> +
>> +#ifdef RTE_LIBRTE_DPAA2_DEBUG_INIT
>> +#define PMD_INIT_FUNC_TRACE() PMD_INIT_LOG(DEBUG, " >>")
>> +#else
>> +#define PMD_INIT_FUNC_TRACE() do { } while (0)
>> +#endif
>> +
>> +#ifdef RTE_LIBRTE_DPAA2_DEBUG_RX
>
> What do you think adding these config option to the config file in this
> patch?
>
I have added them in config file in v2.
>> +#define PMD_RX_LOG(level, fmt, args...) \
>> + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args)
>> +#else
>> +#define PMD_RX_LOG(level, fmt, args...) do { } while (0)
>> +#endif
>> +
>> +#ifdef RTE_LIBRTE_DPAA2_DEBUG_TX
>> +#define PMD_TX_LOG(level, fmt, args...) \
>> + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args)
>> +#else
>> +#define PMD_TX_LOG(level, fmt, args...) do { } while (0)
>> +#endif
>> +
>> +#ifdef RTE_LIBRTE_DPAA2_DEBUG_TX_FREE
>
> This config option was not documented?
>
It is fixed in v2.
>> +#define PMD_TX_FREE_LOG(level, fmt, args...) \
>> + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args)
>> +#else
>> +#define PMD_TX_FREE_LOG(level, fmt, args...) do { } while (0)
>> +#endif
>> +
>> +#ifdef RTE_LIBRTE_DPAA2_DEBUG_DRIVER
>> +#define PMD_DRV_LOG_RAW(level, fmt, args...) \
>> + RTE_LOG(level, PMD, "%s(): " fmt, __func__, ## args)
>> +#else
>> +#define PMD_DRV_LOG_RAW(level, fmt, args...) do { } while (0)
>> +#endif
>> +
>> +#define PMD_DRV_LOG(level, fmt, args...) \
>> + PMD_DRV_LOG_RAW(level, fmt "\n", ## args)
>> +
>> +#endif /* _DPAA2_LOGS_H_ */
>>
>
>
^ permalink raw reply
* Re: [PATCH 02/32] drivers/common: introducing dpaa2 mc driver
From: Hemant Agrawal @ 2016-12-19 15:23 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, bruce.richardson, shreyansh.jain,
Cristian Sovaiala
In-Reply-To: <20161217095535.GA25710@localhost.localdomain>
On 12/17/2016 3:25 PM, Jerin Jacob wrote:
> On Sun, Dec 04, 2016 at 11:46:57PM +0530, Hemant Agrawal wrote:
>> This patch intoduces the DPAA2 MC(Management complex Driver)
>>
>> This driver is common to be used by various DPAA2 net, crypto
>> and other drivers
>>
>> Signed-off-by: Cristian Sovaiala <cristian.sovaiala@nxp.com>
>> [Hemant:rebase and conversion to library for DPDK]
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>
>> include $(RTE_SDK)/mk/rte.vars.mk
>>
>> +DIRS-y += common
>> DIRS-y += net
>> DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
>>
>> diff --git a/drivers/common/Makefile b/drivers/common/Makefile
>> new file mode 100644
>> index 0000000..0c3f35f
>> --- /dev/null
>> +++ b/drivers/common/Makefile
>> @@ -0,0 +1,36 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2016 NXP. 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 NXP 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 $(RTE_SDK)/mk/rte.vars.mk
>> +
>> +DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2
>
> If you are planning to build "external pool" driver or "eventdev" driver or net
> pmd driver as stand alone build then you could try generating the config for
> common code by selection of "external pool" or "eventdev" or net-pmd driver.
> something like below
>
> CONFIG_RTE_LIBRTE_OCTEONTX_COMMON = $(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF)
> ifneq ($(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON),y)
> CONFIG_RTE_LIBRTE_OCTEONTX_COMMON =
> $(CONFIG_RTE_LIBRTE_MEMPOOL_OCTEONTX_FPAVF)
> endif
> ifneq ($(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON),y)
> CONFIG_RTE_LIBRTE_OCTEONTX_COMMON = $(CONFIG_RTE_LIBRTE_PMD_OCTEONTX)
> endif
>
> DIRS-$(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON) += octeontx
>
>
>
Thanks for the suggestion. I have tried it in the V2.
I am still having issue when using shared compilation, currently I am
not able to specify another driver in the DEPDIR
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox