Re: [dpdk-dev] [dpdk-users] [DISCUSSION] code snippet documentation
Regards,
Asaf Penso
>-Original Message-
>From: Ferruh Yigit
>Sent: Friday, July 23, 2021 3:04 PM
>To: Ajit Khaparde ; NBU-Contact-Thomas
>Monjalon
>Cc: Asaf Penso ; us...@dpdk.org; dpdk-dev
>; David Marchand ; Bruce
>Richardson ; Jerin Jacob Kollanukkaran
>; Akhil Goyal ; Maxime Coquelin
>; Honnappa Nagarahalli
>; Tu, Lijuan
>Subject: Re: [dpdk-users] [DISCUSSION] code snippet documentation
>
>On 7/23/2021 1:02 AM, Ajit Khaparde wrote:
>> On Thu, Jul 22, 2021 at 1:29 PM Thomas Monjalon
>wrote:
>>>
>>> 15/07/2021 09:01, Asaf Penso:
Hello DPDK community,
I would like to bring up a discussion about a way to have code snippets as
an
>example for proper usage.
The DPDK tree is filled with great pieces of code that are well documented
>and maintained in high quality.
I feel we are a bit behind when we talk about usage examples.
One way, whenever we implement a new feature, is to extend one of the
>test-* under the "app" folder.
This, however, provides means to test but doesn't provide a good usage
>example.
Another way is to check the content of the "example" folder and whenever
>we have a BIG new feature it seems like a good place.
This, however, doesn't provide a good option when we talk about small
>features.
If, for example, we extend rte_flow with an extra action then providing a
full-
>blown example application is somewhat an entry barrier.
A third option could be to document it in one of the .rst files we have.
Obviously, this requires high maintenance and no option to assure it still
>compiles.
I'd like to propose another approach that will address the main two issues:
>remove the entry barrier and assure compilation.
In this approach, inside the "examples" folder we'll create another folder
for
>"snippets".
Inside "snippets" we'll have several files per category, for
example, rte_flow_snippets.c Each .c file will include a main function that
>calls the different use cases we want to give as an example.
The purpose is not to generate traffic nor read rx/tx packets from the DPDK
>ports.
The purpose is to have a good example that compiles properly.
Taking the rte_flow_snippets.c as an example its main function would look
>like this:
int
main(int argc, char **argv)
{
rte_flow_snippet_match_5tuple_and_drop();
rte_flow_snippet_match_geneve_ope_and_rss();
...
Return 0;
}
>>>
>>> I think we need to have a policy or justification about which snippet
>>> is worth to have.
>>> My thought is to avoid creating snippets which have no other value
>>> than showing a function call.
>>> I think there is a value if the context is not simple.
>>
>> I agree. Otherwise it will be cluttered with snippets.
>>
>
>I sometimes use DTS code as sample for an API, that has limited context (which
>I
>believe sometimes needed to understand API properly) and of course compiles
>fine.
>
>What about making mandatory to add a test to DTS for each API/feature, that
>ensures a reasonable sample for the API call.
>
>And if the intent is just to provide sample for API call without context, I
>believe
>test-* can help on that, it clarifies good & bad input for an API.
>
Thank you Ferruh, Ajit, and Thomas for your replies.
I think the more snippets the merrier and we can categorize them for better
visibility inside the file and among different files.
Limiting would miss the point of having valid code examples for a variety of
cases.
For complex code snippets I fully think that a dedicated test/example app
should be written but my intention of the snippets is something simpler.
Reading only documentation is not practical enough and reviewing an example app
requires too much effort. Snippet is a great tool in between.
Written DTS test can be an option but I think it is too much overhead if one
just wants to show how to use a function or an object, without putting effort
for the "administrative" topics around the snippet.
>>>
>>>
>>> Please could you provide a more complex example?
>>>
>>>
Re: [dpdk-dev] [PATCH] net/iavf: fix tx thresh check issue
> -Original Message- > From: dev On Behalf Of Xing, Beilei > Sent: Friday, July 23, 2021 10:43 AM > To: Li, Xiaoyun ; dev@dpdk.org; Wu, Jingjing > > Cc: sta...@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/iavf: fix tx thresh check issue > > > > > -Original Message- > > From: Li, Xiaoyun > > Sent: Thursday, July 22, 2021 3:56 PM > > To: dev@dpdk.org; Wu, Jingjing ; Xing, Beilei > > > > Cc: Li, Xiaoyun ; sta...@dpdk.org > > Subject: [PATCH] net/iavf: fix tx thresh check issue > > > > Function check_tx_thresh is called with wrong parameter. If the check > > fails, tx_queue_setup should return error not keep going. > > iThis patch fixes above issues. > > Typo: This > > Except that, > Acked-by: Beilei Xing Applied to dpdk-next-net-intel with typo fix Thanks Qi
Re: [dpdk-dev] [PATCH] net/iavf: fix virtual channel RSS command error handling
> -Original Message-
> From: dev On Behalf Of Alvin Zhang
> Sent: Wednesday, July 21, 2021 2:32 PM
> To: Xing, Beilei
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/iavf: fix virtual channel RSS command error
> handling
>
> Kernel PF may not respond to virtual channel commands
> VIRTCHNL_OP_GET_RSS_HENA_CAPS and VIRTCHNL_OP_SET_RSS_HENA,
> which will cause VF to fail to start.
>
> RSS offload type configuration is not a necessary feature for VF, so in order
> to
> improve VF compatibility, in this patch the PMD will ignore the error result
> of
> above two commands and will print warnings instead.
>
> Fixes: 5a038d19962d ("net/iavf: fix RSS configuration on i40e VF")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alvin Zhang
> ---
> drivers/net/iavf/iavf_ethdev.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
> index
> 41382c6..162f55d 100644
> --- a/drivers/net/iavf/iavf_ethdev.c
> +++ b/drivers/net/iavf/iavf_ethdev.c
> @@ -259,7 +259,7 @@ struct rte_iavf_xstats_name_off {
> return err;
> }
>
> -static int
> +static void
> iavf_config_rss_hf(struct iavf_adapter *adapter, uint64_t rss_hf) {
> static const uint64_t map_hena_rss[] = { @@ -319,8 +319,12 @@ struct
> rte_iavf_xstats_name_off {
> int ret;
>
> ret = iavf_get_hena_caps(adapter, &caps);
> - if (ret)
> - return ret;
> + if (ret) {
> + PMD_DRV_LOG(WARNING,
> + "fail to get supported RSS caps, lack PF support");
This is misleading, the failure reason is not necessary be "lack PF support',
it could be any other reason
So better just print the error code here, or simply ignore if a meaningful
failure message will already be printed inside iavf_get_hena_caps.
> + return;
> + }
> +
> /**
>* ETH_RSS_IPV4 and ETH_RSS_IPV6 can be considered as 2
>* generalizations of all other IPv4 and IPv6 RSS types.
> @@ -343,8 +347,11 @@ struct rte_iavf_xstats_name_off {
> }
>
> ret = iavf_set_hena(adapter, hena);
> - if (ret)
> - return ret;
> + if (ret) {
> + PMD_DRV_LOG(WARNING,
> + "fail to clean existing RSS, lack PF support");
Actually this is not the case to "clean" but "overwrite", also the "lack PF
support" should be refined base on previous comments.
> + return;
> + }
>
> if (valid_rss_hf & ipv4_rss)
> valid_rss_hf |= rss_hf & ETH_RSS_IPV4; @@ -357,7 +364,6 @@
> struct rte_iavf_xstats_name_off {
> rss_hf & ~valid_rss_hf);
>
> vf->rss_hf = valid_rss_hf;
> - return 0;
> }
>
> static int
> @@ -409,9 +415,7 @@ struct rte_iavf_xstats_name_off {
> return ret;
> }
> } else {
> - ret = iavf_config_rss_hf(adapter, rss_conf->rss_hf);
> - if (ret != -ENOTSUP)
> - return ret;
> + iavf_config_rss_hf(adapter, rss_conf->rss_hf);
> }
>
> return 0;
> @@ -1400,9 +1404,7 @@ static int iavf_config_rx_queues_irqs(struct
> rte_eth_dev *dev,
> return ret;
> }
> } else {
> - ret = iavf_config_rss_hf(adapter, rss_conf->rss_hf);
> - if (ret != -ENOTSUP)
> - return ret;
> + iavf_config_rss_hf(adapter, rss_conf->rss_hf);
> }
>
> return 0;
> --
> 1.8.3.1
Re: [dpdk-dev] Question about hardware error handling policy
Hi From: fengchengwen: > On 2021/7/22 23:46, Thomas Monjalon wrote: > > 22/07/2021 15:50, fengchengwen: > >> Hi, all > >> > >> I notice ethdev support dev_reset ops, which could be used to > >> recover from errors, and only 13+ drivers support this function. > >> And also there is event for reset: RTE_ETH_EVENT_INTR_RESET, and > >> only 6 drivers support it (most of them are VF). > >> > >> This provides users with two ways to handle hardware errors: > >> a. driver report RTE_ETH_EVENT_INTR_RESET, and application do reset > ops. > >> b. application detect errors (the detection method is unclear), and > >> call > >> reset ops to recover. > >> > >> According to the design of this API, error handling is assigned > >> to the application, and the driver is only responsible for reporting > >> events. This simplifies the driver design (for example, the driver > >> does not need to maintain mutex locks). > >> > >> As we know, many modern NICs come with firmware, have PCIE > >> interfaces, support SR-IOV, the hardware errors can have: firmware > >> reboot/PF reset/ VF reset/FLR, but these errors(particularly > >> firmware/PF) are not addressed in most drivers. > >> > >> Question 1: what do we think of these errors(particularly > >> firmware/PF)? Do we think that the probability is very low and that > >> there is no need to deal with them? > > > > Even rare errors must be managed. > > Because intel and mlx NIC are widely used, I look at i40e/mlx5 driver code, > and found: > 1) i40e PF driver, it only show logs when detect global reset and other error: > if (icr0 & I40E_PFINT_ICR0_GRST_MASK) > PMD_DRV_LOG(INFO, "ICR0: global reset requested"); > if (icr0 & I40E_PFINT_ICR0_PCI_EXCEPTION_MASK) > PMD_DRV_LOG(INFO, "ICR0: PCI exception activated"); > if (icr0 & I40E_PFINT_ICR0_STORM_DETECT_MASK) > PMD_DRV_LOG(INFO, "ICR0: a change in the storm control > state"); >@Beilei Why not report RESET_EVENT in these cases ? or these error are > very rarely >so just report it. And also, the application may still send or recv packet, > These >resets, if not handled correctly, do not cause the hardware/driver to hang > ? > > 2) mlx5 PF driver, I notice there is a mlx5_dev_interrupt_device_fatal which > will remove the device. >@Matan Why not report RESET_EVENT in these cases ? so the application > can be recovered quickly. RTE_ETH_EVENT_INTR_RMV is reported by the driver to notify the app that the device was physically plugged out from the PCI slot. So, when the app sees this event, it should free all the SW resources of this device(call port close to the PMD by the way). RTE_ETH_EVENT_INTR_RESET, /**< reset interrupt event, sent to VF on PF reset */ Looks like VF-PF communication, this is not our case of plugged out which is more fatal. Matan > > > >> Question 2: I prefer to put error handling in the application > >> layer, because doing it in the driver can make the driver complex, > >> but there is no app to register the INTR_RESET event handler. I think > >> we can build a standard handler in testpmd, What do you think? > > > > Absolutely. As any ethdev API, it must be tested with testpmd. > > > > > > . > >
Re: [dpdk-dev] [PATCH v1 0/8] gro: support TCP/IPv6 and UDP/IPv6 for VLAN and VXLAN
> -Original Message- > From: Thomas Monjalon > Sent: Saturday, July 24, 2021 4:49 PM > To: yang_y...@163.com; Hu, Jiayu > Cc: dev@dpdk.org; Ananyev, Konstantin ; > yangy...@inspur.com > Subject: Re: [dpdk-dev] [PATCH v1 0/8] gro: support TCP/IPv6 and UDP/IPv6 > for VLAN and VXLAN > > 24/03/2021 22:22, Thomas Monjalon: > > 21/12/2020 04:50, yang_y...@163.com: > > > Yi Yang (8): > > > gro: support TCP/IPv6 > > > gro: support IPv4 VXLAN TCP/IPv6 > > > gro: support IPv6 VXLAN TCP/IPv4 > > > gro: support IPv6 VXLAN TCP/IPv6 > > > gro: support UDP/IPv6 > > > gro: support IPv4 VXLAN UDP/IPv6 > > > gro: support IPv6 VXLAN UDP/IPv4 > > > gro: support IPv6 VXLAN UDP/IPv6 > > > > There was no review/activity on this thread. > > Is it abandoned? > > No reply. Should I assume it can be dropped? No further updates from Yi on this patch set. So I guess "yes"? Thanks, Jiayu >
Re: [dpdk-dev] [PATCH v16] app/testpmd: support multi-process
在 2021/7/24 19:45, Thomas Monjalon 写道: 10/07/2021 05:50, Min Hu (Connor): This patch adds multi-process support for testpmd. For example the following commands run two testpmd processes: * the primary process: ./dpdk-testpmd --proc-type=auto -l 0-1 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=0 * the secondary process: ./dpdk-testpmd --proc-type=auto -l 2-3 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=1 Signed-off-by: Min Hu (Connor) Signed-off-by: Lijun Ou Signed-off-by: Andrew Rybchenko Acked-by: Xiaoyun Li Acked-by: Ajit Khaparde Reviewed-by: Ferruh Yigit --- V16: * revert unrelated changes. * add some restrictions in doc. I didn't see clear agreement to integrate this feature in DPDK 21.08. BTW, the testpmd maintainer was not Cc'ed. Hi, Thomas, This patch has two "acked" and one "reviewed-by". And Xiaoyun Li is the maintainer, I has already Cc'ed to him/her, please check it out, thanks. .
Re: [dpdk-dev] [PATCH 3/4] doc: update bonding mode 8023ad info
Acked-by: Min Hu (Connor) 在 2021/7/21 23:58, Martin Havlik 写道: Included info on dedicated queues and added related note about issue on mlx5. Signed-off-by: Martin Havlik --- doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst index 30c56cd375..19c65f314c 100644 --- a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst +++ b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst @@ -116,10 +116,18 @@ Currently the Link Bonding PMD library supports following modes of operation: #. Calls to ``rte_eth_tx_burst`` must have a buffer size of at least 2xN, where N is the number of slaves. This is a space required for LACP frames. Additionally LACP packets are included in the statistics, but they are not returned to the application. +This mode also supports enabling dedicated rx and tx queues for handling +LACP frames separately from fast application path, resulting in +a potential performance improvement. + +.. note:: +Currently mlx5 doesn't work with enabled dedicated queues due to +an issue with RTE flow rule creation prior to port start. + * **Transmit Load Balancing (Mode 5):** .. figure:: img/bond-mode-5.* Transmit Load Balancing (Mode 5)
[dpdk-dev] [PATCH] crypto/cnxk: add null check for rsa param key data
From: Kiran Kumar K
Coverity is reporting FORWARD_NULL issue when qt data is NULL.
Adding NULL check for this.
Coverity issue: 371893
Fixes: 5a3513caeb455 ("crypto/cnxk: add asymmetric session ops")
Signed-off-by: Kiran Kumar K
---
drivers/crypto/cnxk/cnxk_ae.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h
index c752e62ea5..a71e7ee8a2 100644
--- a/drivers/crypto/cnxk/cnxk_ae.h
+++ b/drivers/crypto/cnxk/cnxk_ae.h
@@ -85,6 +85,9 @@ cnxk_ae_fill_rsa_params(struct cnxk_ae_sess *sess,
size_t len = (mod_len / 2);
uint64_t total_size;
+ if (qt.p.length != 0 && qt.p.data == NULL)
+ return -EINVAL;
+
/* Make sure key length used is not more than mod_len/2 */
if (qt.p.data != NULL)
len = RTE_MIN(len, qt.p.length);
@@ -109,7 +112,8 @@ cnxk_ae_fill_rsa_params(struct cnxk_ae_sess *sess,
rsa->qt.dQ.data = rsa->qt.q.data + qt.q.length;
memcpy(rsa->qt.dQ.data, qt.dQ.data, qt.dQ.length);
rsa->qt.p.data = rsa->qt.dQ.data + qt.dQ.length;
- memcpy(rsa->qt.p.data, qt.p.data, qt.p.length);
+ if (qt.p.data != NULL)
+ memcpy(rsa->qt.p.data, qt.p.data, qt.p.length);
rsa->qt.dP.data = rsa->qt.p.data + qt.p.length;
memcpy(rsa->qt.dP.data, qt.dP.data, qt.dP.length);
rsa->qt.qInv.data = rsa->qt.dP.data + qt.dP.length;
--
2.25.1
[dpdk-dev] [PATCH 1/3] common/cnxk: add const values to ec groups
From: Kiran Kumar K
New ucode expects const values A and B for asymmetric ECDSA
messages. Adding roc support for this.
Signed-off-by: Kiran Kumar K
---
drivers/common/cnxk/roc_ae.c | 70 ++--
drivers/common/cnxk/roc_ae.h | 17 -
2 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/drivers/common/cnxk/roc_ae.c b/drivers/common/cnxk/roc_ae.c
index cf3f7fc5f2..929da05983 100644
--- a/drivers/common/cnxk/roc_ae.c
+++ b/drivers/common/cnxk/roc_ae.c
@@ -23,6 +23,16 @@ const struct roc_ae_ec_group ae_ec_grp[ROC_AE_EC_ID_PMAX] = {
0x99, 0xDE, 0xF8, 0x36, 0x14, 0x6B,
0xC9, 0xB1, 0xB4, 0xD2, 0x28, 0x31},
.length = 24},
+ .consta = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC},
+ .length = 24},
+ .constb = {.data = {0x64, 0x21, 0x05, 0x19, 0xE5, 0x9C,
+ 0x80, 0xE7, 0x0F, 0xA7, 0xE9, 0xAB,
+ 0x72, 0x24, 0x30, 0x49, 0xFE, 0xB8,
+ 0xDE, 0xEC, 0xC1, 0x46, 0xB9, 0xB1},
+ .length = 24},
},
{
.prime = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
@@ -35,6 +45,16 @@ const struct roc_ae_ec_group ae_ec_grp[ROC_AE_EC_ID_PMAX] = {
0X16, 0XA2, 0XE0, 0XB8, 0XF0, 0X3E, 0X13,
0XDD, 0X29, 0X45, 0X5C, 0X5C, 0X2A, 0X3D},
.length = 28},
+ .consta = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFE},
+ .length = 28},
+ .constb = {.data = {0xB4, 0x05, 0x0A, 0x85, 0x0C, 0x04, 0xB3,
+ 0xAB, 0xF5, 0x41, 0x32, 0x56, 0x50, 0x44,
+ 0xB0, 0xB7, 0xD7, 0xBF, 0xD8, 0xBA, 0x27,
+ 0x0B, 0x39, 0x43, 0x23, 0x55, 0xFF, 0xB4},
+ .length = 28},
},
{
.prime = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00,
@@ -49,6 +69,18 @@ const struct roc_ae_ec_group ae_ec_grp[ROC_AE_EC_ID_PMAX] = {
0x17, 0x9E, 0x84, 0xF3, 0xB9, 0xCA, 0xC2,
0xFC, 0x63, 0x25, 0x51},
.length = 32},
+ .consta = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFC},
+ .length = 32},
+ .constb = {.data = {0x5A, 0xC6, 0x35, 0xD8, 0xAA, 0x3A, 0x93,
+ 0xE7, 0xB3, 0xEB, 0xBD, 0x55, 0x76, 0x98,
+ 0x86, 0xBC, 0x65, 0x1D, 0x06, 0xB0, 0xCC,
+ 0x53, 0xB0, 0xF6, 0x3B, 0xCE, 0x3C, 0x3E,
+ 0x27, 0xD2, 0x60, 0x4B},
+ .length = 32},
},
{.prime = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
@@ -63,7 +95,21 @@ const struct roc_ae_ec_group ae_ec_grp[ROC_AE_EC_ID_PMAX] = {
0xC7, 0x63, 0x4D, 0x81, 0xF4, 0x37, 0x2D, 0xDF,
0x58, 0x1A, 0x0D, 0xB2, 0x48, 0xB0, 0xA7, 0x7A,
0xEC, 0xEC, 0x19, 0x6A, 0xCC, 0xC5, 0x29, 0x73},
- .length = 48}},
+ .length = 48},
+.consta = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFE,
+0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFC},
+ .length = 48},
+.constb = {.data = {0xB3, 0x31, 0x2F, 0xA7, 0xE2, 0x3E, 0xE7, 0xE4,
+0x98, 0x8E, 0x05, 0x6B, 0xE3, 0xF8, 0x2D, 0x19,
+0x18, 0x1D, 0x9C, 0x6E, 0xFE, 0x81, 0x41, 0x12,
+
[dpdk-dev] [PATCH 3/3] common/cpt: update asym ECDSA messages in sync with ucode
From: Kiran Kumar K
Adding changes to asymmetric ECDSA messages to align with
the new ucode for octeontx2 device.
Signed-off-by: Kiran Kumar K
---
drivers/common/cpt/cpt_mcode_defines.h | 17 +-
drivers/common/cpt/cpt_ucode_asym.h| 267 +++--
2 files changed, 176 insertions(+), 108 deletions(-)
diff --git a/drivers/common/cpt/cpt_mcode_defines.h
b/drivers/common/cpt/cpt_mcode_defines.h
index f63fae6b59..f16ee44297 100644
--- a/drivers/common/cpt/cpt_mcode_defines.h
+++ b/drivers/common/cpt/cpt_mcode_defines.h
@@ -220,7 +220,10 @@ typedef enum {
CPT_EC_ID_P256 = 2,
CPT_EC_ID_P384 = 3,
CPT_EC_ID_P521 = 4,
- CPT_EC_ID_PMAX = 5
+ CPT_EC_ID_P160 = 5,
+ CPT_EC_ID_P320 = 6,
+ CPT_EC_ID_P512 = 7,
+ CPT_EC_ID_PMAX = 8
} cpt_ec_id_t;
typedef struct sglist_comp {
@@ -344,6 +347,18 @@ struct cpt_ec_group {
uint8_t data[66];
unsigned int length;
} order;
+
+ struct {
+ /* P521 maximum length */
+ uint8_t data[66];
+ unsigned int length;
+ } consta;
+
+ struct {
+ /* P521 maximum length */
+ uint8_t data[66];
+ unsigned int length;
+ } constb;
};
struct cpt_asym_ec_ctx {
diff --git a/drivers/common/cpt/cpt_ucode_asym.h
b/drivers/common/cpt/cpt_ucode_asym.h
index 50c6f58d3a..a67ded642a 100644
--- a/drivers/common/cpt/cpt_ucode_asym.h
+++ b/drivers/common/cpt/cpt_ucode_asym.h
@@ -486,117 +486,150 @@ cpt_enqueue_rsa_op(struct rte_crypto_op *op,
static const struct cpt_ec_group ec_grp[CPT_EC_ID_PMAX] = {
{
.prime = {
- .data = {
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFE,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
+ .data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF,
+0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF},
+ .length = 24,
},
- .length = 24,
- },
- .order = {
- .data = {
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xFF, 0xFF, 0xFF, 0xFF, 0x99, 0xDE, 0xF8, 0x36,
- 0x14, 0x6B, 0xC9, 0xB1, 0xB4, 0xD2, 0x28, 0x31
- },
- .length = 24
- },
+ .order = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0x99, 0xDE, 0xF8, 0x36, 0x14, 0x6B,
+ 0xC9, 0xB1, 0xB4, 0xD2, 0x28, 0x31},
+ .length = 24},
+ .consta = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC},
+ .length = 24},
+ .constb = {.data = {0x64, 0x21, 0x05, 0x19, 0xE5, 0x9C,
+ 0x80, 0xE7, 0x0F, 0xA7, 0xE9, 0xAB,
+ 0x72, 0x24, 0x30, 0x49, 0xFE, 0xB8,
+ 0xDE, 0xEC, 0xC1, 0x46, 0xB9, 0xB1},
+ .length = 24},
},
{
- .prime = {
- .data = {
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x01
- },
- .length = 28
- },
- .order = {
- .data = {
- 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF,
- 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0X16, 0XA2,
- 0XE0, 0XB8, 0XF0, 0X3E, 0X13, 0XDD, 0X29, 0X45,
- 0X5C, 0X5C, 0X2A, 0X3D
- },
- .length = 28
- },
+ .prime = {.data = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01},
+
[dpdk-dev] [PATCH 2/3] crypto/cnxk: update asym ECDSA messages in sync with ucode
From: Kiran Kumar K Adding changes to asymmetric ECDSA messages to align with the new ucode for cnxk device. Signed-off-by: Kiran Kumar K --- drivers/crypto/cnxk/cnxk_ae.h| 24 drivers/crypto/cnxk/cnxk_cryptodev.h | 2 +- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h index c752e62ea5..174a940ab8 100644 --- a/drivers/crypto/cnxk/cnxk_ae.h +++ b/drivers/crypto/cnxk/cnxk_ae.h @@ -439,7 +439,7 @@ cnxk_ae_ecdsa_sign_prep(struct rte_crypto_ecdsa_op_param *ecdsa, * Please note, private key, order cannot exceed prime * length i.e 3 * p_align. */ - dlen = sizeof(fpm_table_iova) + k_align + m_align + p_align * 3; + dlen = sizeof(fpm_table_iova) + k_align + m_align + p_align * 5; memset(dptr, 0, dlen); @@ -461,12 +461,18 @@ cnxk_ae_ecdsa_sign_prep(struct rte_crypto_ecdsa_op_param *ecdsa, memcpy(dptr, ecdsa->message.data, message_len); dptr += m_align; + memcpy(dptr, ec_grp->consta.data, prime_len); + dptr += p_align; + + memcpy(dptr, ec_grp->constb.data, prime_len); + dptr += p_align; + /* Setup opcodes */ w4.s.opcode_major = ROC_AE_MAJOR_OP_ECDSA; w4.s.opcode_minor = ROC_AE_MINOR_OP_ECDSA_SIGN; w4.s.param1 = curveid | (message_len << 8); - w4.s.param2 = k_len; + w4.s.param2 = (pkey_len << 8) | k_len; w4.s.dlen = dlen; inst->w4.u64 = w4.u64; @@ -521,7 +527,7 @@ cnxk_ae_ecdsa_verify_prep(struct rte_crypto_ecdsa_op_param *ecdsa, * Please note sign, public key and order can not exceed prime length * i.e. 6 * p_align */ - dlen = sizeof(fpm_table_iova) + m_align + (6 * p_align); + dlen = sizeof(fpm_table_iova) + m_align + (8 * p_align); memset(dptr, 0, dlen); @@ -549,6 +555,12 @@ cnxk_ae_ecdsa_verify_prep(struct rte_crypto_ecdsa_op_param *ecdsa, memcpy(dptr + qy_offset, ecdsa->q.y.data, qy_len); dptr += p_align; + memcpy(dptr, ec_grp->consta.data, prime_len); + dptr += p_align; + + memcpy(dptr, ec_grp->constb.data, prime_len); + dptr += p_align; + /* Setup opcodes */ w4.s.opcode_major = ROC_AE_MAJOR_OP_ECDSA; w4.s.opcode_minor = ROC_AE_MINOR_OP_ECDSA_VERIFY; @@ -612,7 +624,7 @@ cnxk_ae_ecpm_prep(struct rte_crypto_ecpm_op_param *ecpm, * scalar length), * Please note point length is equivalent to prime of the curve */ - dlen = 3 * p_align + scalar_align; + dlen = 5 * p_align + scalar_align; x1_offset = prime_len - x1_len; y1_offset = prime_len - y1_len; @@ -628,6 +640,10 @@ cnxk_ae_ecpm_prep(struct rte_crypto_ecpm_op_param *ecpm, dptr += scalar_align; memcpy(dptr, ec_grp->prime.data, ec_grp->prime.length); dptr += p_align; + memcpy(dptr, ec_grp->consta.data, ec_grp->consta.length); + dptr += p_align; + memcpy(dptr, ec_grp->constb.data, ec_grp->constb.length); + dptr += p_align; /* Setup opcodes */ w4.s.opcode_major = ROC_AE_MAJOR_OP_ECC; diff --git a/drivers/crypto/cnxk/cnxk_cryptodev.h b/drivers/crypto/cnxk/cnxk_cryptodev.h index ff46d16e58..b3856f7eaa 100644 --- a/drivers/crypto/cnxk/cnxk_cryptodev.h +++ b/drivers/crypto/cnxk/cnxk_cryptodev.h @@ -13,7 +13,7 @@ #define CNXK_CPT_MAX_CAPS 34 #define CNXK_SEC_CRYPTO_MAX_CAPS 4 #define CNXK_SEC_MAX_CAPS 3 -#define CNXK_AE_EC_ID_MAX 5 +#define CNXK_AE_EC_ID_MAX 8 /** * Device private data */ -- 2.25.1
Re: [dpdk-dev] [PATCH] doc: announce removal of ABIs in PCI bus driver
Hi, Ferruh > -Original Message- > From: Yigit, Ferruh > Sent: Friday, July 23, 2021 8:47 PM > To: Xia, Chenbo ; dev@dpdk.org; tho...@monjalon.net > Cc: m...@ashroe.eu; nhor...@tuxdriver.com; david.march...@redhat.com > Subject: Re: [dpdk-dev] [PATCH] doc: announce removal of ABIs in PCI bus > driver > > On 7/23/2021 8:39 AM, Xia, Chenbo wrote: > > Hi, > > > > A gentle ping for comments.. > > > >> -Original Message- > >> From: dev On Behalf Of Chenbo Xia > >> Sent: Tuesday, June 1, 2021 4:42 PM > >> To: dev@dpdk.org; tho...@monjalon.net > >> Cc: m...@ashroe.eu; nhor...@tuxdriver.com > >> Subject: [dpdk-dev] [PATCH] doc: announce removal of ABIs in PCI bus > driver > >> > >> All ABIs in PCI bus driver, which are defined in rte_buc_pci.h, > >> will be removed and the header will be made internal. > >> > >> Signed-off-by: Chenbo Xia > >> --- > >> doc/guides/rel_notes/deprecation.rst | 5 + > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index 9584d6bfd7..b01f46c62e 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -147,3 +147,8 @@ Deprecation Notices > >> * cmdline: ``cmdline`` structure will be made opaque to hide platform- > >> specific > >>content. On Linux and FreeBSD, supported prior to DPDK 20.11, > >>original structure will be kept until DPDK 21.11. > >> + > >> +* pci: To reduce unnecessary ABIs exposed by DPDK bus driver, > "rte_bus_pci.h" > >> + will be made internal in 21.11 and macros/data structures/functions > defined > >> + in the header will not be considered as ABI anymore. This change is > >> inspired > >> + by the RFC > https://patchwork.dpdk.org/project/dpdk/list/?series=17176. > > > > I see there's some ABI improvement work on-going and I think it could be > part of > > the work. If it makes sense to you, I'd like some ACKs. > > > > Acked-by: Ferruh Yigit > > I am for reducing the public ABI as much as possible. How big will the > change > be? Is the 'rte_bus_pci.h' used other than './drivers/bus/pci/'? I don't see big change here. And I am not sure if I understand your second question. The rte_bus_pci.h will still be used by drivers (maybe remove the rte prefix and change the file name). Thanks, Chenbo
Re: [dpdk-dev] Question about hardware error handling policy
Hi On 2021/7/25 23:12, Matan Azrad wrote: > Hi > > From: fengchengwen: >> On 2021/7/22 23:46, Thomas Monjalon wrote: >>> 22/07/2021 15:50, fengchengwen: Hi, all I notice ethdev support dev_reset ops, which could be used to recover from errors, and only 13+ drivers support this function. And also there is event for reset: RTE_ETH_EVENT_INTR_RESET, and only 6 drivers support it (most of them are VF). This provides users with two ways to handle hardware errors: a. driver report RTE_ETH_EVENT_INTR_RESET, and application do reset >> ops. b. application detect errors (the detection method is unclear), and call reset ops to recover. According to the design of this API, error handling is assigned to the application, and the driver is only responsible for reporting events. This simplifies the driver design (for example, the driver does not need to maintain mutex locks). As we know, many modern NICs come with firmware, have PCIE interfaces, support SR-IOV, the hardware errors can have: firmware reboot/PF reset/ VF reset/FLR, but these errors(particularly firmware/PF) are not addressed in most drivers. Question 1: what do we think of these errors(particularly firmware/PF)? Do we think that the probability is very low and that there is no need to deal with them? >>> >>> Even rare errors must be managed. >> >> Because intel and mlx NIC are widely used, I look at i40e/mlx5 driver code, >> and found: >> 1) i40e PF driver, it only show logs when detect global reset and other >> error: >> if (icr0 & I40E_PFINT_ICR0_GRST_MASK) >> PMD_DRV_LOG(INFO, "ICR0: global reset requested"); >> if (icr0 & I40E_PFINT_ICR0_PCI_EXCEPTION_MASK) >> PMD_DRV_LOG(INFO, "ICR0: PCI exception activated"); >> if (icr0 & I40E_PFINT_ICR0_STORM_DETECT_MASK) >> PMD_DRV_LOG(INFO, "ICR0: a change in the storm control >> state"); >>@Beilei Why not report RESET_EVENT in these cases ? or these error are >> very rarely >>so just report it. And also, the application may still send or recv >> packet, >> These >>resets, if not handled correctly, do not cause the hardware/driver to >> hang ? >> >> 2) mlx5 PF driver, I notice there is a mlx5_dev_interrupt_device_fatal which >> will remove the device. >>@Matan Why not report RESET_EVENT in these cases ? so the application >> can be recovered quickly. > > RTE_ETH_EVENT_INTR_RMV is reported by the driver to notify the app that the > device was physically plugged out from the PCI slot. > So, when the app sees this event, it should free all the SW resources of this > device(call port close to the PMD by the way). > > RTE_ETH_EVENT_INTR_RESET, /**< reset interrupt event, sent to VF on PF > reset */ > Looks like VF-PF communication, this is not our case of plugged out which is > more fatal. I think it can be changed so that the PF can also be used. > > Matan > > >>> Question 2: I prefer to put error handling in the application layer, because doing it in the driver can make the driver complex, but there is no app to register the INTR_RESET event handler. I think we can build a standard handler in testpmd, What do you think? >>> >>> Absolutely. As any ethdev API, it must be tested with testpmd. >>> >>> >>> . >>>
Re: [dpdk-dev] [PATCH v16] app/testpmd: support multi-process
26/07/2021 02:26, Min Hu (Connor): > 在 2021/7/24 19:45, Thomas Monjalon 写道: > > 10/07/2021 05:50, Min Hu (Connor): > >> This patch adds multi-process support for testpmd. > >> For example the following commands run two testpmd > >> processes: > >> > >> * the primary process: > >> > >> ./dpdk-testpmd --proc-type=auto -l 0-1 -- -i \ > >> --rxq=4 --txq=4 --num-procs=2 --proc-id=0 > >> > >> * the secondary process: > >> > >> ./dpdk-testpmd --proc-type=auto -l 2-3 -- -i \ > >> --rxq=4 --txq=4 --num-procs=2 --proc-id=1 > >> > >> Signed-off-by: Min Hu (Connor) > >> Signed-off-by: Lijun Ou > >> Signed-off-by: Andrew Rybchenko > >> Acked-by: Xiaoyun Li > >> Acked-by: Ajit Khaparde > >> Reviewed-by: Ferruh Yigit > >> --- > >> V16: > >> * revert unrelated changes. > >> * add some restrictions in doc. > > > > I didn't see clear agreement to integrate this feature in DPDK 21.08. > > > > BTW, the testpmd maintainer was not Cc'ed. > > > Hi, Thomas, > This patch has two "acked" and one "reviewed-by". > And Xiaoyun Li is the maintainer, I has already Cc'ed to him/her, > please check it out, thanks. Andrew's comment from v15: " IMHO, as I state above, current state is insufficient to consider is a start point to be applied. "
[dpdk-dev] [PATCH] ethdev: modify comment of INTR RESET event
According to the definition of rte_eth_dev_reset(), the
RTE_ETH_EVENT_INTR_RESET event could also use when PF resets.
This patch modifies the comment of RTE_ETH_EVENT_INTR_RESET event, so
that it could use in all resets.
Signed-off-by: Chengwen Feng
---
lib/ethdev/rte_ethdev.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index d2b27c3..e6646a6 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -3499,8 +3499,7 @@ enum rte_eth_event_type {
RTE_ETH_EVENT_INTR_LSC, /**< lsc interrupt event */
RTE_ETH_EVENT_QUEUE_STATE,
/**< queue state event (enabled/disabled) */
- RTE_ETH_EVENT_INTR_RESET,
- /**< reset interrupt event, sent to VF on PF reset */
+ RTE_ETH_EVENT_INTR_RESET, /**< reset interrupt event */
RTE_ETH_EVENT_VF_MBOX, /**< message from the VF received by PF */
RTE_ETH_EVENT_MACSEC, /**< MACsec offload related event */
RTE_ETH_EVENT_INTR_RMV, /**< device removal event */
--
2.8.1
Re: [dpdk-dev] [PATCH v10] dmadev: introduce DMA device library
Friendly ping. On 2021/7/20 20:46, Chengwen Feng wrote: > This patch introduce 'dmadevice' which is a generic type of DMA > device. > > The APIs of dmadev library exposes some generic operations which can > enable configuration and I/O with the DMA devices. > > Signed-off-by: Chengwen Feng > --- > v10: > * fix rte_dmadev_completed_status comment. [snip]
