RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
Hi Arek, Akhil,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, May 25, 2022 12:06 PM
> To: Akhil Goyal ; dev@dpdk.org; Kiran Kumar
> Kokkilagadda ; Anoob Joseph
>
> Cc: Zhang, Roy Fan
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
>
>
>
> > -Original Message-
> > From: Akhil Goyal
> > Sent: Wednesday, May 25, 2022 8:06 AM
> > To: Kusztal, ArkadiuszX ; dev@dpdk.org;
> > Kiran Kumar Kokkilagadda ; Anoob Joseph
> >
> > Cc: Zhang, Roy Fan
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > > > > - removed asymnetric crypto xform next field.
> > > > > Rationale behind having chaining in symmetric crypto was a fact
> > > > > that encryption and authentication are usually done on the same
> > > > > set of data independent of algorithm.
> > > > > HW usually will be able to handle it in one PCI call.
> > > > > In asymmetric there is no such relation between algorithms,
> > > > > therefore next field would be useless.
> > > > >
> > > > > Signed-off-by: Arek Kusztal
> > > >
> > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > private key generation followed by public generation.
> > > [Arek] And why do chaining when this can be done even with one bit flag.
> > >
> > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > please confirm.
> >
> > If we are removing it, then documentation should be in sync.
> [Arek] - although, we may keep it for now, I am not dropping it in v2. DH
> priv +
> pub can be done with priv_key.len = 0 -> similar as 'k' in ecdsa when k.data =
> NULL.
> But I do not see any situation for now it will be useful, it may be dropped
> later if
> not application found.
> >
> > > Also, currently API does not support chaining of
> > > > symmetric and asymmetric crypto xforms.
> > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > asymmetric. One I can think of was once proposed DH + DSA
> > > integration for random number. But not much else, although we can
> > > keep it around for a
> > while.
> >
> > Yes it is highly unlikely to use this combination.
[Anoob] We may need this support when we add EdDSA support. That would involve
a asymmetric operation after hash is generated (symmetric).
https://en.wikipedia.org/wiki/EdDSA#Ed25519
And, asymmetric chaining may become useful when we have PMDs capable of doing
more operations together (like the case with EdDSA). So my preference would be
to retain the 'next' field in asym crypto xform.
> >
> > > >
> > > > > ---
> > > > > lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > 1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > 100644
> > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > * Structure describing asym xforms.
> > > > > */
> > > > > struct rte_crypto_asym_xform {
> > > > > - struct rte_crypto_asym_xform *next;
> > > > > - /**< Pointer to next xform to set up xform chain.*/
> > > > > enum rte_crypto_asym_xform_type xform_type;
> > > > > /**< Asymmetric crypto transform */
> > > > >
> > > > > --
> > > > > 2.13.6
RE: [PATCH v2] app/procinfo: show all non-owned ports
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, 25 May 2022 08.04
>
> On Tue, 24 May 2022 22:46:05 -0700
> Subendu Santra wrote:
>
> > Show all non-owned ports when no port mask is specified
> >
> > show-port option without the mask option, displays only the last
> > non-owned port. Show all the non-owned ports instead.
> >
> > Fixes: 1dd6cffb6571 ("app/procinfo: provide way to request info on
> owned
> > ports")
> > Cc: step...@networkplumber.org
> >
> > Signed-off-by: Subendu Santra
> > ---
> > app/proc-info/main.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/proc-info/main.c b/app/proc-info/main.c
> > index 56070a3317..2be24b584e 100644
> > --- a/app/proc-info/main.c
> > +++ b/app/proc-info/main.c
> > @@ -1504,10 +1504,10 @@ main(int argc, char **argv)
> > if (nb_ports == 0)
> > rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n");
> >
> > - /* If no port mask was specified, then show non-owned ports */
> > + /* If no port mask was specified, then show all non-owned ports
> */
> > if (enabled_port_mask == 0) {
> > RTE_ETH_FOREACH_DEV(i)
> > - enabled_port_mask = 1ul << i;
> > + enabled_port_mask |= (1ul << i);
>
> Ok, looks good. parens on that line are unnecessary
>
> Note: this still will have issues with >32 ports on 32 bit platforms.
The default max_ethports value in meson_options.txt is 32, so the probability
is low.
> But other tools probably have same problem.
It was decided many years ago to extend the port_id type from uint8_t to
uint16_t, mainly to support a high number of virtual ports. So it is not good
that the applications have not been updated accordingly.
However, as Stephen also mentions, this is not unique to this tool, so we'll
just ignore it.
>
> Acked-by: Stephen Hemminger
Acked-by: Morten Brørup
Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI
25/05/2022 02:11, Zhang, Qi Z: > From: Thomas Monjalon > > 24/05/2022 15:42, Zhang, Qi Z: > > > From: Thomas Monjalon > > > > 18/05/2022 02:03, Zhang, Qi Z: > > > > > From: Jeff Daly > > > > > > > > > > > > Some SFP link partners exhibit a disinclination to autonegotiate > > > > > > with X550 configured in SFI mode. This patch enables a manual > > > > > > AN-37 restart to work around the problem. > > > > > > > > > > This fix for some specific hardware in base code, unfortunately > > > > > Intel DPDK team don't have the device and the knowledge to approve > > > > > this, > > > > > > > > That's why the work is collaborative. > > > > You should get and trust knowledge from partners. > > > > The only concerns of a maintainer should be: > > > > - good feature design > > > > - good code quality > > > > > > These are the questions we can't answer, we don't understand the > > > design, what is " change mode enforcement rules to hybrid " means, > > > what is manual AN-37 here and what those numbers in the patch means. > > > > So these are the basic questions you should ask to be made clear in the > > patch. > > That's the same for everybody: we must understand the reason and the > > intent of any change. > > > > > Of cause we trust knowledge from our partners, but anyway this is an > > > Intel product, > > > > The DPDK driver is not an Intel product. > > This a community effort where anyone should be able to participate. > > I'm taking about the hardware not the driver. The SFP is not an Intel product. > > > only Intel have the right to authenticate this. > > > > What do you mean by "authenticate"? You forgot this question. What do you mean by "authenticate"? > > > unfortunately none of the active ixgbe DPDK maintainers and I have the > > > knowledge Meanwhile if this is an issue on DPDK, it could also be an > > > issue on kernel driver that's why we suggest to submit to Linux > > > community first where will be right people to answer above questions. > > > > Why Linux community is more able to review than DPDK, or FreeBSD, or > > Windows, or any other community? > > Of cause DPDK could be able to, if the people have the corresponding > knowledge that works on it > I would say on this very specific domain, DPDK community has the gap that > depends on Intel, > Nothing else, we just try to provide workable suggestion based on current > situation, meanwhile we will escalate. You can get the knowledge by asking the right questions. > > > > - no regression in known cases > > > > > > > > the base code is delivered by our kernel software team, I will > > > > > suggest you can send this to the kernel community to get the right > > > > > expert to review. > > > > > > > > Which kind of expert do you imagine to review? > > > > Intel team or Silicom people who are pushing these improvements? > > > > > > > There is another problem with asking Linux kernel change first: > > > > the patch will land in GPL code, bringing difficulties to move in > > > > BSD-licensed base code. > > > > > > Only if the author agree to share the copy right to Intel, so Intel is > > > able to re-license it to BSD as same as other base code. > > > > Yes we should be able to grant such copyright in the commit message. > > > > > > I suggest we make this process more flexible: > > > > 1/ a contributor sends a patch for DPDK base code > > > >with an explicit grant for backporting in any license. > > > > 2/ Intel checks that there is no DPDK regression > > > > 3/ patch is merged in DPDK > > > > 4/ Intel merges it in the internal base code > > > > 5/ Linux kernel team can backport the fix to Linux > > > > 6/ Any other OS can backport the fix in its driver > > > > > > Right now, our base code in kernel is GPL license only, code with > > > BSD-3-clause can't be distrusted without change our license strategy, > > > so it's the same effort if someone want to backport DPDK changes to > > > kernel (shared the copy right to Intel) > > > > > > but I like your suggestion (if I understand correctly), have a dual > > > licenses in kernel base code make things smoothly to backport from > > > DPDK to kernel, I will feedback this. > > > > > > > Let's make the DPDK process open for everybody. > > > > > > For sure, we should.
Re: [EXT] Re: [dpdk-stable] [PATCH v2] test: avoid hang if queues are full and Tx fails
I'm pretty sure there is something wrong in the driver cnxk, but you keep insisting and nobody complained, so I accept the patch for the test application. Applied 24/05/2022 07:39, Rakesh Kudurumalla: > ping > > > From: Rakesh Kudurumalla > > Sent: Monday, May 9, 2022 3:32 PM > > > > Hi Thomas Monjalon, > > > > Same behavior is observed in cnxk driver as well. > > Can we please get this patch merged ? > > > > > From: Rakesh Kudurumalla > > > Sent: Monday, February 14, 2022 10:27 AM > > > > > > > > octeontx2 driver is removed > > > > Can we close this patch? > > > Same behavior is observed with cnxk driver, so we need this patch > > > > > > > > 01/02/2022 07:30, Rakesh Kudurumalla: > > > > > ping > > > > > > > > > > > From: Rakesh Kudurumalla > > > > > > Sent: Monday, January 10, 2022 2:35 PM > > > > > > > > > > > > ping > > > > > > > > > > > > > From: Rakesh Kudurumalla > > > > > > > Sent: Monday, December 13, 2021 12:10 PM > > > > > > > > From: Thomas Monjalon > > > > > > > > Sent: Monday, November 29, 2021 2:44 PM > > > > > > > > 29/11/2021 09:52, Rakesh Kudurumalla: > > > > > > > > > From: Thomas Monjalon > > > > > > > > > > 22/11/2021 08:59, Rakesh Kudurumalla: > > > > > > > > > > > From: Thomas Monjalon > > > > > > > > > > > > 20/07/2021 18:50, Rakesh Kudurumalla: > > > > > > > > > > > > > Current pmd_perf_autotest() in continuous mode > > > > > > > > > > > > > tries to enqueue MAX_TRAFFIC_BURST completely > > > > > > > > > > > > > before starting the > > > > > > test. > > > > > > > > > > > > > Some drivers cannot accept complete > > > > > > > > > > > > > MAX_TRAFFIC_BURST even though > > > > > > > > > > rx+tx > > > > > > > > > > > > > desc > > > > > > > > > > > > count > > > > > > > > > > > > > can fit it. > > > > > > > > > > > > > > > > > > > > > > > > Which driver is failing to do so? > > > > > > > > > > > > Why it cannot enqueue 32 packets? > > > > > > > > > > > > > > > > > > > > > > Octeontx2 driver is failing to enqueue because > > > > > > > > > > > hardware buffers are full > > > > > > > > > > before test. > > > > > > > > > > > > > > > > Aren't you stopping the support of octeontx2? > > > > > > > > Why do you care now? > > > > > > > > yes we are not supporting octeontx2,but this issue is > > > > > > > > observed in cnxk driver ,current patch fixes the same > > > > > > > > > > > > > > > > > > > > Why hardware buffers are full? > > > > > > > > > Hardware buffers are full because number of number of > > > > > > > > > descriptors in continuous mode Is less than > > > > > > > > > MAX_TRAFFIC_BURST, so if enque fails , there is no way > > > > > > > > > hardware > > > can drop the Packets . > > > > > > > > > pmd_per_autotest application evaluates performance after > > > > > > > > > enqueueing > > > > > > packets Initially. > > > > > > > > > > > > > > > > > > > > > pmd_perf_autotest() in continuous mode tries to > > > > > > > > > > > enqueue MAX_TRAFFIC_BURST (2048) before starting the > > test. > > > > > > > > > > > > > > > > > > > > > > > > This patch changes behaviour to stop enqueuing > > > > > > > > > > > > > after few > > > > > > retries. > > > > > > > > > > > > > > > > > > > > > > > > If there is a real limitation, there will be issues > > > > > > > > > > > > in more places than this test program. > > > > > > > > > > > > I feel it should be addressed either in the driver > > > > > > > > > > > > or at ethdev > > > > level.
Re: [PATCH] avoid AltiVec keyword vector
04/05/2022 22:40, David Christensen: > On 5/3/22 5:03 AM, Thomas Monjalon wrote: > > The keyword "vector" may conflict easily. > > As a rule, it is better to use the alternative keyword "__vector". > > > > Signed-off-by: Thomas Monjalon > > Reviewed-by: David Christensen Applied with a longer explanation: The AltiVec header file is defining "vector", except in C++ build. The keyword "vector" may conflict easily. As a rule, it is better to use the alternative keyword "__vector", so we will be able to #undef vector after including AltiVec header. Later it may become possible to #undef vector in rte_altivec.h with a compatibility breakage.
RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, May 25, 2022 3:56 PM > To: Zhang, Qi Z > Cc: Daly, Jeff ; dev@dpdk.org; Wang, Haiyue > ; ferruh.yi...@amd.com; > andrew.rybche...@oktetlabs.ru; Richardson, Bruce > ; Mcnamara, John > > Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link > partners for X550 SFI > > 25/05/2022 02:11, Zhang, Qi Z: > > From: Thomas Monjalon > > > 24/05/2022 15:42, Zhang, Qi Z: > > > > From: Thomas Monjalon > > > > > 18/05/2022 02:03, Zhang, Qi Z: > > > > > > From: Jeff Daly > > > > > > > > > > > > > > Some SFP link partners exhibit a disinclination to > > > > > > > autonegotiate with X550 configured in SFI mode. This patch > > > > > > > enables a manual > > > > > > > AN-37 restart to work around the problem. > > > > > > > > > > > > This fix for some specific hardware in base code, > > > > > > unfortunately Intel DPDK team don't have the device and the > > > > > > knowledge to approve this, > > > > > > > > > > That's why the work is collaborative. > > > > > You should get and trust knowledge from partners. > > > > > The only concerns of a maintainer should be: > > > > > - good feature design > > > > > - good code quality > > > > > > > > These are the questions we can't answer, we don't understand the > > > > design, what is " change mode enforcement rules to hybrid " means, > > > > what is manual AN-37 here and what those numbers in the patch means. > > > > > > So these are the basic questions you should ask to be made clear in the > patch. > > > That's the same for everybody: we must understand the reason and the > > > intent of any change. > > > > > > > Of cause we trust knowledge from our partners, but anyway this is > > > > an Intel product, > > > > > > The DPDK driver is not an Intel product. > > > This a community effort where anyone should be able to participate. > > > > I'm taking about the hardware not the driver. > > The SFP is not an Intel product. I'm talking about supported ixgbe NICs , that's patch will impact. https://doc.dpdk.org/guides/nics/ixgbe.html > > > > > only Intel have the right to authenticate this. > > > > > > What do you mean by "authenticate"? > > You forgot this question. > What do you mean by "authenticate"? I mean a hardware vendor to judge if a configure is correct or not on its own product. Btw, I may not express this clearly in previous, I would say "responsibility" but not the "right" > > > > > unfortunately none of the active ixgbe DPDK maintainers and I have > > > > the knowledge Meanwhile if this is an issue on DPDK, it could also > > > > be an issue on kernel driver that's why we suggest to submit to > > > > Linux community first where will be right people to answer above > questions. > > > > > > Why Linux community is more able to review than DPDK, or FreeBSD, or > > > Windows, or any other community? > > > > Of cause DPDK could be able to, if the people have the corresponding > > knowledge that works on it I would say on this very specific domain, > > DPDK community has the gap that depends on Intel, Nothing else, we just > try to provide workable suggestion based on current situation, meanwhile > we will escalate. > > You can get the knowledge by asking the right questions. > > > > > > - no regression in known cases > > > > > > > > > > the base code is delivered by our kernel software team, I will > > > > > > suggest you can send this to the kernel community to get the > > > > > > right expert to review. > > > > > > > > > > Which kind of expert do you imagine to review? > > > > > Intel team or Silicom people who are pushing these improvements? > > > > > > > > > There is another problem with asking Linux kernel change first: > > > > > the patch will land in GPL code, bringing difficulties to move > > > > > in BSD-licensed base code. > > > > > > > > Only if the author agree to share the copy right to Intel, so > > > > Intel is able to re-license it to BSD as same as other base code. > > > > > > Yes we should be able to grant such copyright in the commit message. > > > > > > > > I suggest we make this process more flexible: > > > > > 1/ a contributor sends a patch for DPDK base code > > > > > with an explicit grant for backporting in any license. > > > > > 2/ Intel checks that there is no DPDK regression > > > > > 3/ patch is merged in DPDK > > > > > 4/ Intel merges it in the internal base code > > > > > 5/ Linux kernel team can backport the fix to Linux > > > > > 6/ Any other OS can backport the fix in its driver > > > > > > > > Right now, our base code in kernel is GPL license only, code with > > > > BSD-3-clause can't be distrusted without change our license > > > > strategy, so it's the same effort if someone want to backport DPDK > > > > changes to kernel (shared the copy right to Intel) > > > > > > > > but I like your suggestion (if I understand correctly), have a > > > > dual licenses in kernel base code ma
Re: [PATCH v6 6/9] net/vmxnet3: add version 6 support
Hi, Pankaj, On 5/25/22 03:40, Pankaj Gupta wrote: VMXNET3 version 6 supports some new features, including but not limited to: - Increased max MTU up to 9190 - Increased max number of queues, both for Rx and Tx - Removes power-of-two limitations - Extended interrupt structures, required implementation for additional number of queues Tested, using testpmd, for different hardware versions on ESXi 7.0 Update 2. Signed-off-by: Pankaj Gupta Reviewed-by: Jochen Behrens --- doc/guides/rel_notes/release_21_08.rst | 8 + drivers/net/vmxnet3/base/vmxnet3_defs.h | 73 ++-- drivers/net/vmxnet3/vmxnet3_ethdev.c| 220 +--- drivers/net/vmxnet3/vmxnet3_ethdev.h| 10 +- drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +- 5 files changed, 234 insertions(+), 79 deletions(-) diff --git a/doc/guides/rel_notes/release_21_08.rst b/doc/guides/rel_notes/release_21_08.rst index 4027bd4390..810da2cc1f 100644 --- a/doc/guides/rel_notes/release_21_08.rst +++ b/doc/guides/rel_notes/release_21_08.rst @@ -133,6 +133,14 @@ New Features * **Added RETA query and RETA update support for vmxnet3.** +* **Added vmxnet3 version 6 supports with some new features.** + + * Increased max MTU up to 9190 + * Increased max number of queues, both for Rx and Tx + * Removes power-of-two limitations + * Extended interrupt structures, required implementation for additional number +of queues + I've realized that I don't understand the last bullet. Could you clarify it, please, and I'll update it on applying. Also, JFYI, you should update release notes for 22.07 release, not old release notes for 21.08. Don't worry about it now - I'll move and rephrase it on applying. Thanks, Andrew.
Re: [PATCH v8 2/5] ethdev: common utilities for different SFF specs
On 5/25/22 06:14, Robin Zhang wrote: This patch implements SFF-8024 Rev 4.0 of pluggable I/O configuration and some common utilities for SFF-8436/8636 and SFF-8472/8079. Signed-off-by: Robin Zhang [snip] checkpatches.sh complains on the following, please, fix: + /* SFP Temp in 16-bit signed 1/256 Celcius */ Celcius -> Celsius
RE: [PATCH v2] net/iavf: fix device stop
> -Original Message-
> From: Nicolau, Radu
> Sent: Monday, May 23, 2022 8:05 PM
> To: Wu, Jingjing ; Xing, Beilei
> Cc: dev@dpdk.org; Buckley, Daniel M ; Zhang,
> Qi Z ; Nicolau, Radu ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/iavf: fix device stop
>
> Move security context destroy from device stop to device close function.
> Deleting the context on device stop can prevent the application from
> properly cleaning and releasing resources.
>
> Fixes: 6bc987ecb860 ("net/iavf: support IPsec inline crypto")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Radu Nicolau
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
RE: [PATCH v2] net/igc: add I226 support
> -Original Message- > From: Yang, Qiming > Sent: Wednesday, May 25, 2022 1:58 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Yang, Qiming ; Liu, KevinX > > Subject: [PATCH v2] net/igc: add I226 support > > Added I226 Series device ID in igc driver and updated igc guide document for > new devices. > > Signed-off-by: Qiming Yang > Signed-off-by: Kevin Liu Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
[PATCH] app/eventdev: add Tx first option to pipeline mode
From: Pavan Nikhilesh
Add Tx first support to pipeline mode tests, the transmition is done
on all the ethernet ports. This helps in testing eventdev performance
with standalone loopback interfaces.
Example:
./dpdk-test-eventdev ... -- ... --tx_first 512
512 defines the number of packets to transmit.
Add an option Tx packet size, the default packet size is 64.
Example:
./dpdk-test-eventdev ... -- ... --tx_first 512 --tx_pkt_sz 320
Signed-off-by: Pavan Nikhilesh
---
app/test-eventdev/evt_common.h | 1 +
app/test-eventdev/evt_options.c | 28
app/test-eventdev/evt_options.h | 2 +
app/test-eventdev/test_pipeline_common.c | 165 ++-
app/test-eventdev/test_pipeline_common.h | 2 +
doc/guides/tools/testeventdev.rst| 21 ++-
6 files changed, 214 insertions(+), 5 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index 2f301a7e79..e304998cd7 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -65,6 +65,7 @@ struct evt_options {
uint16_t eth_queues;
uint32_t nb_flows;
uint32_t tx_first;
+ uint16_t tx_pkt_sz;
uint32_t max_pkt_sz;
uint32_t prod_enq_burst_sz;
uint32_t deq_tmo_nsec;
diff --git a/app/test-eventdev/evt_options.c b/app/test-eventdev/evt_options.c
index d3c704d2b3..fb17f5a159 100644
--- a/app/test-eventdev/evt_options.c
+++ b/app/test-eventdev/evt_options.c
@@ -106,6 +106,26 @@ evt_parse_eth_prod_type(struct evt_options *opt, const
char *arg __rte_unused)
return 0;
}
+static int
+evt_parse_tx_first(struct evt_options *opt, const char *arg __rte_unused)
+{
+ int ret;
+
+ ret = parser_read_uint32(&(opt->tx_first), arg);
+
+ return ret;
+}
+
+static int
+evt_parse_tx_pkt_sz(struct evt_options *opt, const char *arg __rte_unused)
+{
+ int ret;
+
+ ret = parser_read_uint16(&(opt->tx_pkt_sz), arg);
+
+ return ret;
+}
+
static int
evt_parse_timer_prod_type(struct evt_options *opt, const char *arg
__rte_unused)
{
@@ -376,6 +396,10 @@ usage(char *program)
"\t--vector_size : Max vector size.\n"
"\t--vector_tmo_ns: Max vector timeout in nanoseconds\n"
"\t--per_port_pool: Configure unique pool per ethdev port\n"
+ "\t--tx_first : Transmit given number of packets\n"
+ " across all the ethernet devices
before\n"
+ " event workers start.\n"
+ "\t--tx_pkt_sz: Packet size to use with Tx first."
);
printf("available tests:\n");
evt_test_dump_names();
@@ -456,6 +480,8 @@ static struct option lgopts[] = {
{ EVT_VECTOR_TMO, 1, 0, 0 },
{ EVT_PER_PORT_POOL, 0, 0, 0 },
{ EVT_HELP,0, 0, 0 },
+ { EVT_TX_FIRST,1, 0, 0 },
+ { EVT_TX_PKT_SZ, 1, 0, 0 },
{ NULL,0, 0, 0 }
};
@@ -497,6 +523,8 @@ evt_opts_parse_long(int opt_idx, struct evt_options *opt)
{ EVT_VECTOR_SZ, evt_parse_vector_size},
{ EVT_VECTOR_TMO, evt_parse_vector_tmo_ns},
{ EVT_PER_PORT_POOL, evt_parse_per_port_pool},
+ { EVT_TX_FIRST, evt_parse_tx_first},
+ { EVT_TX_PKT_SZ, evt_parse_tx_pkt_sz},
};
for (i = 0; i < RTE_DIM(parsermap); i++) {
diff --git a/app/test-eventdev/evt_options.h b/app/test-eventdev/evt_options.h
index 2231c58801..4aa06976b7 100644
--- a/app/test-eventdev/evt_options.h
+++ b/app/test-eventdev/evt_options.h
@@ -51,6 +51,8 @@
#define EVT_VECTOR_SZ("vector_size")
#define EVT_VECTOR_TMO ("vector_tmo_ns")
#define EVT_PER_PORT_POOL ("per_port_pool")
+#define EVT_TX_FIRST("tx_first")
+#define EVT_TX_PKT_SZ ("tx_pkt_sz")
#define EVT_HELP ("help")
void evt_options_default(struct evt_options *opt);
diff --git a/app/test-eventdev/test_pipeline_common.c
b/app/test-eventdev/test_pipeline_common.c
index c66656cd39..82fe04258b 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -56,14 +56,170 @@ processed_pkts(struct test_pipeline *t)
return total;
}
+/* RFC863 discard port */
+#define UDP_SRC_PORT 9
+#define UDP_DST_PORT 9
+
+/* RFC2544 reserved test subnet 192.18.0.0 */
+#define IP_SRC_ADDR(x, y) ((192U << 24) | (18 << 16) | ((x) << 8) | (y))
+#define IP_DST_ADDR(x, y) ((192U << 24) | (18 << 16) | ((x) << 8) | (y))
+
+#define IP_DEFTTL 64 /* from RFC 1340. */
+#define IP_VERSION 0x40
+#define IP_HDRLEN 0x05 /* default IP header length == five 32-bits words. */
+#define IP_VHL_DEF (IP_VERSION | IP_HDRLEN)
+
+static void
+setup_pkt_udp_ip_headers(struct rte_ipv4_hdr *ip_hdr,
+struct rte_udp_hdr *udp_hdr, uint16_t pkt_d
Re: [PATCH v8 5/5] ethdev: format module EEPROM for SFF-8636
On 5/25/22 06:14, Robin Zhang wrote:
This patch implements format module EEPROM information for
SFF-8636 Rev 2.7
Signed-off-by: Robin Zhang
[snip]
+ /*
+* There is no clear identifier to signify the existence of
+* optical diagnostics similar to SFF-8472. So checking existence
+* of page 3, will provide the gurantee for existence of alarms
typo: gurantee -> guarantee (found by checkpatches.sh)
+const uint8_t rx_power_offset[MAX_CHANNEL_NUM] = {
I think it should be "static". You don't need it outside of
corresponding C file.
Also, please, add a namespace prefix "sff_8636_" to make
it easier in the code to understand that the symbol is
global (not function/block local).
+SFF_8636_RX_PWR_1_OFFSET,
TAB must be used to indent. checkpatches.sh complains on it.
Please, run sanity checks yourself before sending patches
upstream as contributor guidelines say.
+SFF_8636_RX_PWR_2_OFFSET,
+SFF_8636_RX_PWR_3_OFFSET,
+SFF_8636_RX_PWR_4_OFFSET,
+};
+const uint8_t tx_power_offset[MAX_CHANNEL_NUM] = {
+SFF_8636_TX_PWR_1_OFFSET,
+SFF_8636_TX_PWR_2_OFFSET,
+SFF_8636_TX_PWR_3_OFFSET,
+SFF_8636_TX_PWR_4_OFFSET,
+};
+const uint8_t tx_bias_offset[MAX_CHANNEL_NUM] = {
+SFF_8636_TX_BIAS_1_OFFSET,
+SFF_8636_TX_BIAS_2_OFFSET,
+SFF_8636_TX_BIAS_3_OFFSET,
+SFF_8636_TX_BIAS_4_OFFSET,
+};
It is wrong to define it in the header. You'll have copies if
the header is included in many C files and linker will dislike it. So,
it should be moved to sff_8636.c
[PATCH] examples/l2fwd: add check of Rx packets count
An additional check is added to avoid extra processing if
receive packets are 0.
Performance impact: with Marvell OCTEON TX2 platform, observed an
improvement by ~14%.
Signed-off-by: Rahul Bhansali
---
examples/l2fwd/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 281c6b7a3f..28c498712e 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -286,6 +286,9 @@ l2fwd_main_loop(void)
nb_rx = rte_eth_rx_burst(portid, 0,
pkts_burst, MAX_PKT_BURST);
+ if (unlikely(nb_rx == 0))
+ continue;
+
port_statistics[portid].rx += nb_rx;
for (j = 0; j < nb_rx; j++) {
--
2.25.1
Re: [PATCH v8 1/5] ethdev: add telemetry command for module EEPROM
On 5/25/22 06:14, Robin Zhang wrote:
Add a new telemetry command /ethdev/module_eeprom to dump the module
EEPROM of each port. The format of module EEPROM information follows
the SFF(Small Form Factor) Committee specifications.
Please, add SFF to devtools/words-case.txt
Signed-off-by: Robin Zhang
---
lib/ethdev/ethdev_sff_telemetry.c | 138 ++
lib/ethdev/ethdev_sff_telemetry.h | 27 ++
I think we should be consistent with naming. Other patches
name added files as sff_*.[ch]. I see no strong reason to
have ethdev_ prefix here. sff_ prefix should be sufficient.
lib/ethdev/meson.build| 1 +
lib/ethdev/rte_ethdev.c | 3 +
4 files changed, 169 insertions(+)
create mode 100644 lib/ethdev/ethdev_sff_telemetry.c
create mode 100644 lib/ethdev/ethdev_sff_telemetry.h
diff --git a/lib/ethdev/ethdev_sff_telemetry.c
b/lib/ethdev/ethdev_sff_telemetry.c
new file mode 100644
index 00..f756b9643f
--- /dev/null
+++ b/lib/ethdev/ethdev_sff_telemetry.c
@@ -0,0 +1,138 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ */
+
+#include
+
+#include
Other C files in ethdev use double-quotes to include headers
provided by the library itself. Also it should go after headers
provided by other DPDK libraries.
+#include
+#include "ethdev_sff_telemetry.h"
+#include "telemetry_data.h"
Why are double quotes used for the include?
It is a header from other DPDK library similar to rte_common.h.
+
+static void
+sff_port_module_eeprom_parse(uint16_t port_id, struct rte_tel_data *d)
+{
+ struct rte_eth_dev_module_info minfo;
+ struct rte_dev_eeprom_info einfo;
+ int ret;
+
+ if (d == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Dict invalid\n");
+ return;
+ }
+
+ ret = rte_eth_dev_get_module_info(port_id, &minfo);
+ if (ret != 0) {
+ switch (ret) {
+ case -ENODEV:
+ RTE_ETHDEV_LOG(ERR, "port index %d invalid\n", port_id);
The majority of ethdev logs start from capital letter. Please,
be consistent.
+ break;
+ case -ENOTSUP:
+ RTE_ETHDEV_LOG(ERR, "operation not supported by
device\n");
same here
+ break;
+ case -EIO:
+ RTE_ETHDEV_LOG(ERR, "device is removed\n");
same here
+ break;
+ default:
+ RTE_ETHDEV_LOG(ERR, "Unable to get port module info,
%d\n", ret);
+ break;
+ }
+ return;
+ }
+
+ einfo.offset = 0;
+ einfo.length = minfo.eeprom_len;
+ einfo.data = calloc(1, minfo.eeprom_len);
+ if (einfo.data == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Allocation of port %u eeprom data
failed\n", port_id);
Please, be consistent in logging: eeprom -> EEPROM as below
+ errno = 0;
+ port_id = strtoul(params, &end_param, 0);
+
+ if (errno != 0) {
+ RTE_ETHDEV_LOG(ERR, "Invalid argument\n");
Please, log the invalid argument (params).
+ return -1;
+ }
+
+ if (*end_param != '\0')
+ RTE_ETHDEV_LOG(NOTICE,
+ "Extra parameters passed to ethdev telemetry command,
ignoring\n");
I think it would be very useful to log these extra parameters.
+
+ rte_tel_data_start_dict(d);
+
+ sff_port_module_eeprom_parse(port_id, d);
+
+ return 0;
+}
[snip]
Re: [PATCH v8 2/5] ethdev: common utilities for different SFF specs
Summary must not be a statement.
Consider: "add common code for different SFF specs" or
something like this.
On 5/25/22 06:14, Robin Zhang wrote:
This patch implements SFF-8024 Rev 4.0 of pluggable I/O configuration
"This patch implements" -> "Add support for"
Basicaly "This patches" does not make sense. It the description
of the patch in any case.
and some common utilities for SFF-8436/8636 and SFF-8472/8079.
Signed-off-by: Robin Zhang
---
lib/ethdev/meson.build | 1 +
lib/ethdev/sff_common.c | 326
lib/ethdev/sff_common.h | 174 +
3 files changed, 501 insertions(+)
create mode 100644 lib/ethdev/sff_common.c
create mode 100644 lib/ethdev/sff_common.h
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index 49c77acb3f..8f39739e43 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -12,6 +12,7 @@ sources = files(
'rte_mtr.c',
'rte_tm.c',
'ethdev_sff_telemetry.c',
+'sff_common.c',
)
headers = files(
diff --git a/lib/ethdev/sff_common.c b/lib/ethdev/sff_common.c
new file mode 100644
index 00..06d96fac72
--- /dev/null
+++ b/lib/ethdev/sff_common.c
@@ -0,0 +1,326 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8024 Rev 4.0 of pluggable I/O configuration and some
+ * common utilities for SFF-8436/8636 and SFF-8472/8079
+ *
Please, remove above extra empty line.
+ */
+
+#include
+#include
Please, add empty line after system headers.
+#include
Why do you need rte_mbuf.h?
+#include
Do you really need it? Looks like no.
+#include
Why do you need rte_flow.h?
+#include "sff_common.h"
+#include "ethdev_sff_telemetry.h"
Library headers should go last and should be included using
double quotes.
[snip]
diff --git a/lib/ethdev/sff_common.h b/lib/ethdev/sff_common.h
new file mode 100644
index 00..264fb915cd
--- /dev/null
+++ b/lib/ethdev/sff_common.h
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8024 Rev 4.0 of pluggable I/O configuration and some
+ * common utilities for SFF-8436/8636 and SFF-8472/8079
+ *
+ */
+
+#ifndef _SFF_COMMON_H_
+#define _SFF_COMMON_H_
+
+#include
+#include
+#include
+#include
+#include "ethdev_sff_telemetry.h"
same comments about headers
+/* Most common case: 16-bit unsigned integer in a certain unit */
+#define OFFSET_TO_U16(offset) \
+ (data[offset] << 8 | data[(offset) + 1])
Please, add SFF_ prefix to all these macros. It will match sff_
prefix of the header name and make it clear in the code which
uses these macros.
+
+#define SPRINT_xX_PWR(str, var) \
SNPRINT_xX_PWR to highlight that it should be safe printing to
a string
+ snprintf(str, sizeof(str), "%.4f mW / %.2f dBm", \
+ (double)((var) / 1.), \
+ convert_mw_to_dbm((double)((var) / 1.)))
+
+#define SPRINT_BIAS(str, bias_cur) \
same here
+ snprintf(str, sizeof(str), "%.3f mA", (double)(bias_cur / 500.))
+
+#define SPRINT_TEMP(str, temp) \
same here
+ snprintf(str, sizeof(str), "%.2f degrees C / %.2f degrees F", \
+ (double)(temp / 256.), \
+ (double)(temp / 256. * 1.8 + 32.))
+
+#define SPRINT_VCC(str, sfp_voltage) \
same here
+ snprintf(str, sizeof(str), "%.4f V", (double)(sfp_voltage /
1.))
+
+/* Channel Monitoring Fields */
+struct sff_channel_diags {
+ uint16_t bias_cur; /* Measured bias current in 2uA units */
+ uint16_t rx_power; /* Measured RX Power */
+ uint16_t tx_power; /* Measured TX Power */
+};
+
+/* Module Monitoring Fields */
+struct sff_diags {
+
+#define MAX_CHANNEL_NUM 4
+#define LWARN 0
+#define HWARN 1
+#define LALRM 2
+#define HALRM 3
+#define MCURR 4
Please, add prefix to these defines as well.
+
+ /* Supports DOM */
+ uint8_t supports_dom;
+ /* Supports alarm/warning thold */
+ uint8_t supports_alarms;
+ /* RX Power: 0 = OMA, 1 = Average power */
+ uint8_t rx_power_type;
+ /* TX Power: 0 = Not supported, 1 = Average power */
+ uint8_t tx_power_type;
+
+ uint8_t calibrated_ext;/* Is externally calibrated */
+ /* [5] tables are low/high warn, low/high alarm, current */
+ /* SFP voltage in 0.1mV units */
+ uint16_t sfp_voltage[5];
+ /* SFP Temp in 16-bit signed 1/256 Celcius */
+ int16_t sfp_temp[5];
+ /* Measured bias current in 2uA units */
+ uint16_t bias_cur[5];
+ /* Measured TX Power */
+ uint16_t tx_power[5];
+ /* Measured RX Power */
+ uint16_t rx_power[5];
+ struct sff_channel_diags scd[MAX_CHANNEL_NUM];
+};
+
+double convert_mw_to_dbm(double mw);
Please, add sff_ prefix
+void sff_show_value_with_unit(const uint8_
[PATCH] eal/ppc: undefine AltiVec keyword vector
The AltiVec header file is defining "vector", except in C++ build. The keyword "vector" may conflict easily. As a rule, it is better to use the alternative keyword "__vector". The DPDK header file rte_altivec.h takes care of undefining "vector", so the applications and dependencies are free to define the name "vector". This is a compatibility breakage for applications which were using the keyword "vector" for its AltiVec meaning. Signed-off-by: Thomas Monjalon --- doc/guides/rel_notes/release_22_07.rst | 5 + lib/eal/ppc/include/rte_altivec.h | 7 +++ 2 files changed, 12 insertions(+) diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst index e49cacecef..ee60b17821 100644 --- a/doc/guides/rel_notes/release_22_07.rst +++ b/doc/guides/rel_notes/release_22_07.rst @@ -133,6 +133,11 @@ API Changes Also, make sure to start the actual text at the margin. === +* The DPDK header file ``rte_altivec.h``, + which is a wrapper for the PPC header file ``altivec.h``, + undefines the AltiVec keyword ``vector``. + The alternative keyword ``__vector`` should be used instead. + ABI Changes --- diff --git a/lib/eal/ppc/include/rte_altivec.h b/lib/eal/ppc/include/rte_altivec.h index 1551a94544..7c088d2d16 100644 --- a/lib/eal/ppc/include/rte_altivec.h +++ b/lib/eal/ppc/include/rte_altivec.h @@ -9,6 +9,13 @@ /* To include altivec.h, GCC version must be >= 4.8 */ #include +/* + * The keyword "vector" is defined in altivec.h, + * and often conflicts with code in applications or dependencies. + * It is preferred to use the alternative keyword "__vector". + */ +#undef vector + /* * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11. * Otherwise there would be a type conflict between stdbool and altivec. -- 2.36.0
Re: [PATCH v8 3/5] ethdev: format module EEPROM for SFF-8079
Consider: "support SFF-8079 module information telemetry" (if it fits in required number of symbols) On 5/25/22 06:14, Robin Zhang wrote: This patch implements format module EEPROM information for SFF-8079 Rev 1.7 Add support for module EEPROM information format defined in SFF-8079 Rev 1.7. diff --git a/lib/ethdev/sff_8079.c b/lib/ethdev/sff_8079.c new file mode 100644 index 00..cfa20bd3cb --- /dev/null +++ b/lib/ethdev/sff_8079.c @@ -0,0 +1,406 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2022 Intel Corporation + * + * Implements SFF-8079 optics diagnostics. + * Please, remove extra empty line. + */ + +#include +#include +#include +#include +#include "sff_common.h" +#include "ethdev_sff_telemetry.h" Please, separate system, other DPDK and local headers. Use double quotes for local headers. Remove unnecessary includes. + if (data[3] & (1 << 7)) Use RTE_BIT32 here and in similar cases below + if (data[65] & (1 << 1)) Use RTE_BIT32 here as well. + ssf_add_dict_string(d, name, "RX_LOS implemented");
Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
On Wed, May 25, 2022 at 11:53:07AM +0200, Thomas Monjalon wrote: > The AltiVec header file is defining "vector", except in C++ build. > The keyword "vector" may conflict easily. > As a rule, it is better to use the alternative keyword "__vector". > > The DPDK header file rte_altivec.h takes care of undefining "vector", > so the applications and dependencies are free to define the name "vector". > > This is a compatibility breakage for applications which were using > the keyword "vector" for its AltiVec meaning. > > Signed-off-by: Thomas Monjalon Acked-by: Tyler Retzlaff
RE: [EXT] [RFC] examples/fips_validation: add fips 140-3 acvp aes-cbc test
Hi Brian,
Thanks for the RFC and PFA inline my comments.
> -Original Message-
> From: Brian Dooley
> Sent: Friday, May 20, 2022 9:36 PM
> To: dev@dpdk.org
> Cc: Akhil Goyal ; Gowrishankar Muthukrishnan
> ; Brian Dooley ; Fan
> Zhang
> Subject: [EXT] [RFC] examples/fips_validation: add fips 140-3 acvp aes-cbc
> test
>
> External Email
>
> --
> This RFC patch showcases an alternative approach to enable FIPS 140-3
> support in the DPDK fips_validation sample application.
>
> The approach presented here takes advantage of an existing open source
> library, libacvp,(https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_cisco_libacvp&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r
> =EAtr-g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=Or6tpEsPX87-
> j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=ZnDDms
> 0KubRYj4TCliLrDQ9IO5S27LVUJunrx3vbpUA&e= ) to generate the parsed test
> cases instead of creating and maintaining a DPDK FIPS test file parser. In
> addition call back functions are added to the dpdk-fips_validation application
> to process the parsed test vectors and write back the results.
>
libacvp carries its source code under Apache License v2. Would there be
any license conflict to consume it as parser for fips_validation in DPDK ?
https://github.com/cisco/libacvp/blob/main/LICENSE
> This initial RFC patch contains the code to parse the FIPS 140-3 test files
> with
> libacvp library, and the AES-CBC test runner callback function implementation
> with most test types covered apart from MCT test.
>
> Although a different approach has been proposed
> (https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__patches.dpdk.org_project_dpdk_list_-3Fseries-
> 3D22738&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=EAtr-
> g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=Or6tpEsPX87-
> j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=OlrgMzf
> QefOQwOunfPxgtFcKOid-8-mw1yQVv0_Ncv8&e= ), it has the disadvantage
> of having to maintain the parsing code.
>
We already have stabilized code and good number of parsers from Brandon series
(plus the one I am also topping up - AES_CBC, SHA etc), we can always extend
the parsers
availability as and when needed. Extension also would not be too difficult IMHO
as its
base functions are ready for all sort of extensions (where the real work could
only be to
manipulate with key words for test vectors).
I am also thinking that, NIST will only make changes in a pace that its eco
system can also
follow. So, we can certainly catch up in our releases.
> For the sake of this RFC here is some information on how to modify and run a
> test case.
>
> The libacvp library can be installed by following the Building instructions
> in the
> README of the libacvp repo as linked above.
>
Also libacvp is not available in any of OS distributions
(https://pkgs.org/search/?q=acvp).
Though README is absolutely helping, proper documentation in the context of
consuming it for fips_validation can help better. For eg,
(a) What configure options required (at bare minimum) to support fips app.
(b) Versions of libcurl and openssl that is supported by libacvp
compilation (for fips app.)
(c) cross compilation notes
(d) source code url to download from etc.
Cross compiling with dependent libs is difficult at times when the integrity is
not tested
properly. Hence, DPDK fips_validation would require special instructions apart
from
README IMHO.
> An example test vector which we can call as our input.req:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_cisco_libacvp_blob_main_test_json_aes_aes.json&d=DwI
> DAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=EAtr-
> g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=Or6tpEsPX87-
> j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=JR1nXo6
> 9fg3FQ64fRyNYYYTs1-YU8ziuU5epo0VdRcg&e=
>
> The header acvVersion metadata at the start needs to been updated to the
> following:
>
> {
> "acvVersion": "1.0",
> "jwt": "NA",
> "url": "NA",
> "isSample": false,
> "vectorSetUrls": ["NA"]
> }
Can we manipulate these fields within the app itself instead ?
For eg, url should be NA anyway for the scope of using this library here.
>
> With this RFC patch applied you can then run the dpdk-fips_validation as
> follows:
>
> ./dpdk-fips_validation --vdev=crypto_aesni_mb -- \
> --req-file input.req --rsp-file output.rsp --acvp
>
> Please note the MCT tests in the input.req file will generate an incorrect
> result set as the IV update part has yet to be implemented.
> This will be addressed in next revision.
>
Please give a check on entire results including AFT as well. I did json diff
and learnt
atleast 1500 out of 2156 tests failed for AES_CBC while using this patch
(i.e post tcId 285, many of tests failed including AFT). If it is not the case
for you,
I can cross check once again if anything else going wrong, as none
[PATCH v4 1/2] mem: telemetry support for memseg and element information
Changes adds telemetry support to display memory occupancy
in memseg and the information of the elements allocated from
a memseg based on arguments provided by user. This patch
adds following endpoints:
1. /eal/memseg_list_array
The command displays the memseg list from which the memory
has been allocated.
Example:
--> /eal/memseg_list_array
{"/eal/memseg_list_array": [0, 1]}
2. /eal/memseg_list_info,
The command outputs the memsegs, from which the memory is
allocated, for the memseg_list given as input. Command also
supports help.
Example:
--> /eal/memseg_list_info,help
{"/eal/memseg_list_info": "/eal/memseg_list_info,"}
--> /eal/memseg_list_info,1
{"/eal/memseg_list_info": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, \
12, 13, 14, 15]}
3. /eal/memseg_info,,
The command outputs the memseg information based on the
memseg-list and the memseg-id given as input. Command also
supports help.
Example:
--> /eal/memseg_info,help
{"/eal/memseg_info": "/eal/memseg_info,, \
"}
--> /eal/memseg_info,0,10
{"/eal/memseg_info": {"Memseg_list_index": 0, \
"Memseg_index": 10, "Memseg_list_len": 64, \
"Start_addr": "0x26000", "End_addr": "0x28000", \
"Size": 536870912}}
--> /eal/memseg_info,1,15
{"/eal/memseg_info": {"Memseg_list_index": 1, \
"Memseg_index": 15, "Memseg_list_len": 64, \
"Start_addr": "0xb2000", "End_addr": "0xb4000", \
"Size": 536870912}}
4. /eal/element_list,,,
The command outputs number of elements in a memseg based
on the heap-id, memseg-list-id and memseg-id given as input.
Command also supports help.
Example:
--> /eal/element_list,help
{"/eal/element_list": "/eal/element_list,, \
,"}
--> /eal/element_list,0,0,63
{"/eal/element_list": {"Element_count": 52}}
--> /eal/element_list,0,1,15
{"/eal/element_list": {"Element_count": 52}}
5. /eal/element_info \
,
The command outputs element information like element start
address, end address, to which memseg it belongs, element
state, element size. User can give a range of elements to be
printed. Command also supports help.
Example:
--> /eal/element_info,help
{"/eal/element_info": "/eal/element_info,, \
,,,"}
--> /eal/element_info,0,1,15,1,2
{"/eal/element_info": {"element.1": {"msl_id": 1,\
"ms_id": 15, "memseg_start_addr": "0xb2000", \
"memseg_end_addr": "0xb4000",\
"element_start_addr": "0xb201fe680", \
"element_end_addr": "0xb20bfe700", \
"element_size": 10485888, "element_state": "Busy"}, \
"element.2": {"msl_id": 1, "ms_id": 15, \
"memseg_start_addr": "0xb2000", \
"memseg_end_addr": "0xb4000",\
"element_start_addr": "0xb20bfe700", \
"element_end_addr": "0xb215fe780", "element_size": 10485888, \
"element_state": "Busy"}, "Element_count": 2}}
Signed-off-by: Amit Prakash Shukla
---
v2:
- Fixed compilation error related int-to-pointer-cast
- Changes for code review suggestions
v3:
- Commit message changes
- Renaming end-points
- Changing input parameters to comma-seperated
- Reverting telemetry output buffer size
v4:
- Patch-2 adds telemetry support to display system memory
lib/eal/common/eal_common_memory.c | 482 -
1 file changed, 477 insertions(+), 5 deletions(-)
diff --git a/lib/eal/common/eal_common_memory.c
b/lib/eal/common/eal_common_memory.c
index 688dc615d7..e66de6a872 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -26,6 +26,7 @@
#include "eal_memcfg.h"
#include "eal_options.h"
#include "malloc_heap.h"
+#include "malloc_elem.h"
/*
* Try to mmap *size bytes in /dev/zero. If it is successful, return the
@@ -1113,11 +1114,17 @@ rte_eal_memory_init(void)
}
#ifndef RTE_EXEC_ENV_WINDOWS
-#define EAL_MEMZONE_LIST_REQ "/eal/memzone_list"
-#define EAL_MEMZONE_INFO_REQ "/eal/memzone_info"
-#define EAL_HEAP_LIST_REQ "/eal/heap_list"
-#define EAL_HEAP_INFO_REQ "/eal/heap_info"
-#define ADDR_STR 15
+#define EAL_MEMZONE_LIST_REQ "/eal/memzone_list"
+#define EAL_MEMZONE_INFO_REQ "/eal/memzone_info"
+#define EAL_HEAP_LIST_REQ "/eal/heap_list"
+#define EAL_HEAP_INFO_REQ "/eal/heap_info"
+#define EAL_MEMSEG_LIST_ARR_REQ"/eal/memseg_list_array"
+#define EAL_MEMSEG_LIST_INFO_REQ "/eal/memseg_list_info"
+#define EAL_MEMSEG_INFO_REQ"/eal/memseg_info"
+#define EAL_ELEMENT_LIST_REQ "/eal/element_list"
+#define EAL_ELEMENT_INFO_REQ "/eal/element_info"
+#define ADDR_STR 15
+
/* Telemetry callback handler to return heap stats for requested heap id. */
static int
@@ -1265,6 +1272,454 @@ handle_eal_memzone_list_request(const char *cmd
__rte_unused,
return 0;
}
+static int
+handle_eal_memseg_list_array_request(const char *cmd __rte_unused,
+const char *params __rte_unused,
+
[PATCH v4 2/2] mem: telemetry support for system memory information
Changes adds telemetry support to display system memory information,
allocated using calls malloc, calloc, mmap, etc. This patch
is based on malloc_info. This patch adds following endpoints:
1. /sysmem/sys_heap_list
The commands displays the arenas currently in use.
Example:
--> /sysmem/sys_heap_list
{"/sysmem/sys_heap_list": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
2. /sysmem/sys_heap_info,
This command displays the information about arena.
Example:
--> /sysmem/sys_heap_info,0
{"/sysmem/sys_heap_info": {"Arena_id": 0, "Allocated_size": 2069934, \
"Free_count": 4, "Free_size": 223826, "Curr_size": 2293760, \
"Mmap_count": 0, "Mmap_size": 0, "Heap_count": 0, \
"Heap_size": 2293760}}
--> /sysmem/sys_heap_info,6
{"/sysmem/sys_heap_info": {"Arena_id": 6, "Allocated_size": 3136, \
"Free_count": 2, "Free_size": 193472, "Curr_size": 196608, \
"Mmap_count": 0, "Mmap_size": 0, "Heap_count": 1,\
"Heap_size": 196608}}
The last arena-id in the list gives total of all arenas.
--> /sysmem/sys_heap_info,10
{"/sysmem/sys_heap_info": {"Arena_id": 10, "Allocated_size": 2107774, \
"Free_count": 20, "Free_size": 1955458, "Curr_size": 4063232,\
"Mmap_count": 0, "Mmap_size": 0, "Heap_count": 0,\
"Heap_size": 4063232}}
Signed-off-by: Amit Prakash Shukla
---
lib/eal/common/eal_common_memory.c | 330 +
1 file changed, 330 insertions(+)
diff --git a/lib/eal/common/eal_common_memory.c
b/lib/eal/common/eal_common_memory.c
index e66de6a872..a1677082c1 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -8,6 +8,9 @@
#include
#include
#include
+#ifdef RTE_EXEC_ENV_LINUX
+#include
+#endif
#include
#include
@@ -1123,6 +1126,12 @@ rte_eal_memory_init(void)
#define EAL_MEMSEG_INFO_REQ"/eal/memseg_info"
#define EAL_ELEMENT_LIST_REQ "/eal/element_list"
#define EAL_ELEMENT_INFO_REQ "/eal/element_info"
+
+#ifdef RTE_EXEC_ENV_LINUX
+#define SYSMEMORY_LIST_REQ "/sysmem/sys_heap_list"
+#define SYSMEMORY_INFO_REQ "/sysmem/sys_heap_info"
+#endif
+
#define ADDR_STR 15
@@ -1720,6 +1729,318 @@ handle_eal_element_info_request(const char *cmd
__rte_unused,
return 0;
}
+#ifdef RTE_EXEC_ENV_LINUX
+#define MAX_SYS_MEM_ARENAS 128
+#define MAX_TAG_CHAR 128
+
+/* Memory size are in bytes. */
+struct mem_stats {
+ uint64_t fast_count; /* Number of free blocks in fast bin. */
+ uint64_t fast_size; /* Size in bytes of free blocks in fast bin. */
+ uint64_t rest_count; /* Number of free blocks in bin. */
+ uint64_t rest_size; /* Size in bytes of free blocks in bin. */
+ uint64_t mmap_count; /* Number of mmap blocks. */
+ uint64_t mmap_size; /* Size in bytes of mmap'd memory. */
+ uint64_t curr_size; /* Size in bytes allocated by system. */
+ uint64_t heap_size; /* Heap size in bytes. */
+ uint64_t heap_count; /* Number of heaps. */
+};
+
+struct rte_heap_mem_stats {
+ unsigned int num_active_arena;
+ struct mem_stats stats[MAX_SYS_MEM_ARENAS];
+};
+
+/* This function shall be called to parse only attributes.
+ * Parsing of the "tags" shall be done by the caller.
+ */
+static int
+parse_attr(char *buf, uint32_t *i, char *attr, const char *key)
+{
+ int j = 0;
+ int keymatch = 0;
+
+ attr[j] = '\0';
+
+ while ((buf[*i] != '>') && (j < MAX_TAG_CHAR)) {
+ /* Ignore spaces. */
+ if (buf[*i] == ' ') {
+ attr[j] = '\0';
+ j = 0;
+ (*i)++;
+ continue;
+ }
+
+ /* Attribute key */
+ if (buf[*i] == '=') {
+ attr[j] = '\0';
+ j = 0;
+ (*i)++;
+
+ /* If the key is matched, extract the value. */
+ if (strncmp(attr, key, strlen(key)) != 0)
+ continue;
+ else
+ keymatch = 1;
+ }
+
+ /* Attribute value */
+ if ((buf[*i] == '"') && (keymatch == 1)) {
+ j = 0;
+ (*i)++;
+
+ while ((buf[*i] != '"') && (j < MAX_TAG_CHAR))
+ attr[(j)++] = buf[(*i)++];
+ attr[j] = '\0';
+ (*i)++;
+ return 0;
+ }
+
+ keymatch = 0;
+ attr[(j)++] = buf[(*i)++];
+ }
+
+ (*i)++;
+ return -1;
+}
+
+/* Get the system memory stats into buffer by calling malloc_info().
+ * malloc_info() returns the stats in XML format. Parse the XML to extract
+ * number of heaps, size of each heap, free memory in heap.
+ */
+static int
+parse_heap_mem_stat
Re: [PATCH] ethdev: prohibit polling of a stopped queue
25/04/2022 10:30, Thomas Monjalon:
> 10/04/2022 23:35, Dmitry Kozlyuk:
> > Whether it is allowed to call Rx/Tx functions for a stopped queue
> > was undocumented. Some PMDs make this behavior a no-op
> > either by explicitly checking the queue state
> > or by the way how their routines are implemented or HW works.
> >
> > No-op behavior may be convenient for application developers.
> > But it also means that pollers of stopped queues
> > would go all the way down to PMD Rx/Tx routines, wasting cycles.
> > Some PMDs would do a check for the queue state on data path,
> > even though it may never be needed for a particular application.
> > Also, use cases for stopping queues or starting them deferred
> > do not logically require polling stopped queues.
> >
> > Use case 1: a secondary that was polling the queue has crashed,
> > the primary is doing a recovery to free all mbufs.
> > By definition the queue to be restarted is not polled.
> >
> > Use case 2: deferred queue start or queue reconfiguration.
> > The polling thread must be synchronized anyway,
> > because queue start and stop are non-atomic.
> >
> > Prohibit calling Rx/Tx functions on stopped queues.
> >
> > Fixes: 0748be2cf9a2 ("ethdev: queue start and stop")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Dmitry Kozlyuk
> > ---
> > This patch is was originally a part of the series:
> > http://patchwork.dpdk.org/project/dpdk/patch/20220307125351.697936-3-dkozl...@nvidia.com/
> > The discussion there is summarized in the commit message.
> [...]
> > * rte_eth_rx_queue_setup()), it must call rte_eth_dev_stop() first to
> > stop the
> > * device and then do the reconfiguration before calling
> > rte_eth_dev_start()
> > * again. The transmit and receive functions should not be invoked when the
> > - * device is stopped.
> > + * device is stopped or when the queue is stopped (for that queue).
>
> I think we can make it simpler:
>
> The transmit and receive functions should not be invoked when the device
> or the queue is stopped.
No comment after a month.
The patch is applied in next-net with the suggested rewording.
[PATCH v5] eal: add bus cleanup to eal cleanup
During EAL init, all buses are probed and the devices found are
initialized. On eal_cleanup(), the inverse does not happen, meaning any
allocated memory and other configuration will not be cleaned up
appropriately on exit.
Currently, in order for device cleanup to take place, applications must
call the driver-relevant functions to ensure proper cleanup is done before
the application exits. Since initialization occurs for all devices on the
bus, not just the devices used by an application, it requires a)
application awareness of all bus devices that could have been probed on the
system, and b) code duplication across applications to ensure cleanup is
performed. An example of this is rte_eth_dev_close() which is commonly used
across the example applications.
This patch proposes adding bus cleanup to the eal_cleanup() to make EAL's
init/exit more symmetrical, ensuring all bus devices are cleaned up
appropriately without the application needing to be aware of all bus types
that may have been probed during initialization.
Contained in this patch are the changes required to perform cleanup for
devices on the PCI bus and VDEV bus during eal_cleanup(). There would be an
ask for bus maintainers to add the relevant cleanup for their buses since
they have the domain expertise.
Signed-off-by: Kevin Laatz
Acked-by: Morten Brørup
---
v5:
* remove unnecessary logs
* move rte_bus_cleanup() definition to eal_private.h
* fix return values for vdev_cleanup and pci_cleanup
v4:
* rebase
v3:
* add vdev bus cleanup
v2:
* change log level from INFO to DEBUG for PCI cleanup
* add abignore entries for rte_bus related false positives
---
devtools/libabigail.abignore| 9 +
drivers/bus/pci/pci_common.c| 24
drivers/bus/vdev/vdev.c | 24
lib/eal/common/eal_common_bus.c | 17 +
lib/eal/common/eal_private.h| 10 ++
lib/eal/include/rte_bus.h | 13 +
lib/eal/linux/eal.c | 1 +
7 files changed, 98 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..3e519ee42a 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -56,3 +56,12 @@
; Ignore libabigail false-positive in clang builds, after moving code.
[suppress_function]
name = rte_eal_remote_launch
+
+; Ignore field inserted to rte_bus, adding cleanup function
+[suppress_type]
+name = rte_bus
+has_data_member_inserted_at = end
+
+; Ignore changes to internally used structs containing rte_bus
+[suppress_type]
+name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 37ab879779..5dd486019f 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -394,6 +394,29 @@ pci_probe(void)
return (probed && probed == failed) ? -1 : 0;
}
+static int
+pci_cleanup(void)
+{
+ struct rte_pci_device *dev = NULL;
+ int error = 0;
+
+ FOREACH_DEVICE_ON_PCIBUS(dev) {
+ struct rte_pci_driver *drv = dev->driver;
+ int ret = 0;
+
+ if (drv == NULL)
+ continue;
+
+ ret = drv->remove(dev);
+ if (ret < 0) {
+ rte_errno = errno;
+ error = -1;
+ }
+ }
+
+ return error;
+}
+
/* dump one device */
static int
pci_dump_one_device(FILE *f, struct rte_pci_device *dev)
@@ -813,6 +836,7 @@ struct rte_pci_bus rte_pci_bus = {
.bus = {
.scan = rte_pci_scan,
.probe = pci_probe,
+ .cleanup = pci_cleanup,
.find_device = pci_find_device,
.plug = pci_plug,
.unplug = pci_unplug,
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index a8d8b2327e..78d6e75b89 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -569,6 +569,29 @@ vdev_probe(void)
return ret;
}
+static int
+vdev_cleanup(void)
+{
+ struct rte_vdev_device *dev;
+ int error = 0;
+
+ TAILQ_FOREACH(dev, &vdev_device_list, next) {
+ const char *name;
+ struct rte_vdev_driver *drv;
+ int ret = 0;
+
+ name = rte_vdev_device_name(dev);
+ if (vdev_parse(name, &drv))
+ continue;
+
+ ret = drv->remove(dev);
+ if (ret < 0)
+ error = -1;
+ }
+
+ return error;
+}
+
struct rte_device *
rte_vdev_find_device(const struct rte_device *start, rte_dev_cmp_t cmp,
const void *data)
@@ -627,6 +650,7 @@ vdev_get_iommu_class(void)
static struct rte_bus rte_vdev_bus = {
.scan = vdev_scan,
.probe = vdev_probe,
+ .cleanup = vdev_cleanup,
.find_device = rte_vdev_find_device,
.plug = vdev_plug,
.
Re: [PATCH] app/testpmd: fix use of indirect action after port close
12/04/2022 07:41, Singh, Aman Deep:
> On 4/11/2022 2:01 AM, Dmitry Kozlyuk wrote:
> >> From: Dmitry Kozlyuk
> >> Sent: Thursday, March 31, 2022 1:57 AM
> >> [...]
> >>> From: Singh, Aman Deep
> >>> Sent: Wednesday, March 30, 2022 5:24 PM
> >>> [...]
> >>> On 3/7/2022 10:18 PM, Dmitry Kozlyuk wrote:
> When a port was closed, indirect actions could remain
> with their handles no longer valid.
> If a newly attached device was assigned the same ID as the closed
> >> port,
> those indirect actions became accessible again.
> Any attempt to use them resulted in an undefined behavior.
> Automatically flush indirect actions when a port is closed.
>
> Fixes: 4b61b8774be9 ("ethdev: introduce indirect flow action")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dmitry Kozlyuk
> Acked-by: Matan Azrad
> ---
> >>> From: guides/prog_guide/rte_flow.rst
> >>> /"If ``RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP`` is advertised,//
> >>> //this means that the PMD can keep at least some indirect actions//
> >>> //across device stop and start.
> >>>
> >>> /Please check, if we are inline with the guidelines given in the
> >> section.
> >>
> >> This patch is related to port closing, not port stopping.
> >> Flow API resources are owned by the port,
> >> so they cannot be valid when the port is closed and its ethdev removed.
> >> TestPMD was keeping indirect action handles contrary to this.
> Agreed, at port close these should be flushed. LGTM
>
> Acked-by: Aman Singh
Applied in next-net, thanks.
RE: [EXT] Re: [PATCH] examples/ipsec-secgw: add support of NEON with poll mode
> -Original Message-
> From: Konstantin Ananyev
> Sent: Wednesday, May 25, 2022 4:30 AM
> To: Rahul Bhansali ; dev@dpdk.org; Radu Nicolau
> ; Akhil Goyal ; Ruifeng Wang
>
> Cc: Jerin Jacob Kollanukkaran
> Subject: [EXT] Re: [PATCH] examples/ipsec-secgw: add support of NEON with
> poll mode
>
> External Email
>
> --
> 24/05/2022 10:57, Rahul Bhansali пишет:
> > This adds the support of NEON based lpm lookup along with multi packet
> > processing for burst send in packets routing.
> >
> > Performance impact:
> > On cn10k, with poll mode inline protocol, outbound performance
> > increased by upto ~8% and inbound performance increased by upto ~6%.
>
>
> Interesting, good bunch of code looks like a dup from l3fwd:
> grouping, precessx4_step?, etc.
Yes, neon logic is taken as a reference from l3fwd and some modifications as per
requirement of ipsec example.
> Would it be possible to move dup code into some common place,
> so it can be used by both examples?
processx4_step... has some additional Ethernet header, inline vs non-inline
packets lpm lookup,
IP checksum etc processes and even if we separate out to make common code with
l3fwd then getting
less performance as additional things to be done separately again under certain
conditions for
individual packets.
For grouping specific port_groupx4() only, we can have it in a common place. If
it is worth,
I can make changes accordingly. Do let me know.
>
> >
> > Signed-off-by: Rahul Bhansali
> > ---
> > examples/ipsec-secgw/ipsec-secgw.c| 25 ++
> > examples/ipsec-secgw/ipsec_lpm_neon.h | 213 +++
> > examples/ipsec-secgw/ipsec_neon.h | 487 ++
> > examples/ipsec-secgw/ipsec_worker.c | 9 +
> > 4 files changed, 734 insertions(+)
> > create mode 100644 examples/ipsec-secgw/ipsec_lpm_neon.h
> > create mode 100644 examples/ipsec-secgw/ipsec_neon.h
> >
> > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> secgw/ipsec-secgw.c
> > index 25255e053c..038c4669f5 100644
> > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > @@ -56,6 +56,10 @@
> > #include "parser.h"
> > #include "sad.h"
> >
> > +#if defined(__ARM_NEON)
> > +#include "ipsec_lpm_neon.h"
> > +#endif
> > +
> > volatile bool force_quit;
> >
> > #define MAX_JUMBO_PKT_LEN 9600
> > @@ -96,6 +100,12 @@ struct ethaddr_info
> ethaddr_tbl[RTE_MAX_ETHPORTS] = {
> > { 0, ETHADDR(0x00, 0x16, 0x3e, 0x49, 0x9e, 0xdd) }
> > };
> >
> > +/*
> > + * To hold ethernet header per port, which will be applied
> > + * to outgoing packets.
> > + */
> > +xmm_t val_eth[RTE_MAX_ETHPORTS];
> > +
> > struct flow_info flow_info_tbl[RTE_MAX_ETHPORTS];
> >
> > #define CMD_LINE_OPT_CONFIG "config"
> > @@ -561,9 +571,16 @@ process_pkts(struct lcore_conf *qconf, struct
> rte_mbuf **pkts,
> > process_pkts_outbound(&qconf->outbound, &traffic);
> > }
> >
> > +#if defined __ARM_NEON
> > + /* Neon optimized packet routing */
> > + route4_pkts_neon(qconf->rt4_ctx, traffic.ip4.pkts, traffic.ip4.num,
> > +qconf->outbound.ipv4_offloads, true);
> > + route6_pkts_neon(qconf->rt6_ctx, traffic.ip6.pkts, traffic.ip6.num);
> > +#else
> > route4_pkts(qconf->rt4_ctx, traffic.ip4.pkts, traffic.ip4.num,
> > qconf->outbound.ipv4_offloads, true);
> > route6_pkts(qconf->rt6_ctx, traffic.ip6.pkts, traffic.ip6.num);
> > +#endif
> > }
> >
> > static inline void
> > @@ -1390,6 +1407,8 @@ add_dst_ethaddr(uint16_t port, const struct
> rte_ether_addr *addr)
> > return -EINVAL;
> >
> > ethaddr_tbl[port].dst = ETHADDR_TO_UINT64(addr);
> > + rte_ether_addr_copy((struct rte_ether_addr *)ðaddr_tbl[port].dst,
> > + (struct rte_ether_addr *)(val_eth + port));
> > return 0;
> > }
> >
> > @@ -1852,6 +1871,12 @@ port_init(uint16_t portid, uint64_t
> req_rx_offloads, uint64_t req_tx_offloads)
> > portid, rte_strerror(-ret));
> >
> > ethaddr_tbl[portid].src = ETHADDR_TO_UINT64(ðaddr);
> > +
> > + rte_ether_addr_copy((struct rte_ether_addr *)ðaddr_tbl[portid].dst,
> > + (struct rte_ether_addr *)(val_eth + portid));
> > + rte_ether_addr_copy((struct rte_ether_addr *)ðaddr_tbl[portid].src,
> > + (struct rte_ether_addr *)(val_eth + portid) + 1);
> > +
> > print_ethaddr("Address: ", ðaddr);
> > printf("\n");
> >
> > diff --git a/examples/ipsec-secgw/ipsec_lpm_neon.h b/examples/ipsec-
> secgw/ipsec_lpm_neon.h
> > new file mode 100644
> > index 00..959a5a8666
> > --- /dev/null
> > +++ b/examples/ipsec-secgw/ipsec_lpm_neon.h
> > @@ -0,0 +1,213 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2022 Marvell.
> > + */
> > +
> > +#ifndef __IPSEC_LPM_NEON_H__
> > +#define __IPSEC_LPM_NEON_H__
> > +
> > +#include
> > +#include "ipsec_neo
RE: [PATCH] eal/ppc: undefine AltiVec keyword vector
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, May 25, 2022 12:53 PM > To: dev@dpdk.org > Cc: m...@ashroe.eu; david.march...@redhat.com; techbo...@dpdk.org; > David Christensen > Subject: [PATCH] eal/ppc: undefine AltiVec keyword vector > > The AltiVec header file is defining "vector", except in C++ build. > The keyword "vector" may conflict easily. > As a rule, it is better to use the alternative keyword "__vector". > > The DPDK header file rte_altivec.h takes care of undefining "vector", > so the applications and dependencies are free to define the name "vector". > > This is a compatibility breakage for applications which were using > the keyword "vector" for its AltiVec meaning. > > Signed-off-by: Thomas Monjalon > --- Build passes with latest rdma-core master (36395896) on Ubuntu 20.04.4. Tested-by: Ali Alnubani Thanks, Ali
RE: [PATCH] eal/ppc: undefine AltiVec keyword vector
> -Original Message- > From: Ali Alnubani > Sent: Wednesday, May 25, 2022 2:09 PM > To: Thomas Monjalon ; dev@dpdk.org > Cc: m...@ashroe.eu; david.march...@redhat.com; techbo...@dpdk.org; > David Christensen > Subject: RE: [PATCH] eal/ppc: undefine AltiVec keyword vector > > > -Original Message- > > From: Thomas Monjalon > > Sent: Wednesday, May 25, 2022 12:53 PM > > To: dev@dpdk.org > > Cc: m...@ashroe.eu; david.march...@redhat.com; techbo...@dpdk.org; > > David Christensen > > Subject: [PATCH] eal/ppc: undefine AltiVec keyword vector > > > > The AltiVec header file is defining "vector", except in C++ build. > > The keyword "vector" may conflict easily. > > As a rule, it is better to use the alternative keyword "__vector". > > > > The DPDK header file rte_altivec.h takes care of undefining "vector", > > so the applications and dependencies are free to define the name > "vector". > > > > This is a compatibility breakage for applications which were using > > the keyword "vector" for its AltiVec meaning. > > > > Signed-off-by: Thomas Monjalon > > --- > > Build passes with latest rdma-core master (36395896) on Ubuntu 20.04.4. Compiler: powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 > > Tested-by: Ali Alnubani > > Thanks, > Ali
Re: [PATCH v5] eal: add bus cleanup to eal cleanup
On Wed, May 25, 2022 at 11:39:53AM +0100, Kevin Laatz wrote:
> During EAL init, all buses are probed and the devices found are
> initialized. On eal_cleanup(), the inverse does not happen, meaning any
> allocated memory and other configuration will not be cleaned up
> appropriately on exit.
>
> Currently, in order for device cleanup to take place, applications must
> call the driver-relevant functions to ensure proper cleanup is done before
> the application exits. Since initialization occurs for all devices on the
> bus, not just the devices used by an application, it requires a)
> application awareness of all bus devices that could have been probed on the
> system, and b) code duplication across applications to ensure cleanup is
> performed. An example of this is rte_eth_dev_close() which is commonly used
> across the example applications.
>
> This patch proposes adding bus cleanup to the eal_cleanup() to make EAL's
> init/exit more symmetrical, ensuring all bus devices are cleaned up
> appropriately without the application needing to be aware of all bus types
> that may have been probed during initialization.
>
> Contained in this patch are the changes required to perform cleanup for
> devices on the PCI bus and VDEV bus during eal_cleanup(). There would be an
> ask for bus maintainers to add the relevant cleanup for their buses since
> they have the domain expertise.
>
> Signed-off-by: Kevin Laatz
> Acked-by: Morten Brørup
>
> ---
> v5:
> * remove unnecessary logs
> * move rte_bus_cleanup() definition to eal_private.h
> * fix return values for vdev_cleanup and pci_cleanup
>
Hi Kevin,
few more comments inline below.
Also, with this change, does it mean that we can remove the cleanup done at
the end of testpmd and some other apps? If so, perhaps that should be done
in a separate patch to make this a multi-patch series.
/Bruce
> v4:
> * rebase
>
> v3:
> * add vdev bus cleanup
>
> v2:
> * change log level from INFO to DEBUG for PCI cleanup
> * add abignore entries for rte_bus related false positives
> ---
> devtools/libabigail.abignore| 9 +
> drivers/bus/pci/pci_common.c| 24
> drivers/bus/vdev/vdev.c | 24
> lib/eal/common/eal_common_bus.c | 17 +
> lib/eal/common/eal_private.h| 10 ++
> lib/eal/include/rte_bus.h | 13 +
> lib/eal/linux/eal.c | 1 +
> 7 files changed, 98 insertions(+)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 79ff15dc4e..3e519ee42a 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -56,3 +56,12 @@
> ; Ignore libabigail false-positive in clang builds, after moving code.
> [suppress_function]
> name = rte_eal_remote_launch
> +
> +; Ignore field inserted to rte_bus, adding cleanup function
> +[suppress_type]
> +name = rte_bus
> +has_data_member_inserted_at = end
> +
> +; Ignore changes to internally used structs containing rte_bus
> +[suppress_type]
> +name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
> diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
> index 37ab879779..5dd486019f 100644
> --- a/drivers/bus/pci/pci_common.c
> +++ b/drivers/bus/pci/pci_common.c
> @@ -394,6 +394,29 @@ pci_probe(void)
> return (probed && probed == failed) ? -1 : 0;
> }
>
> +static int
> +pci_cleanup(void)
> +{
> + struct rte_pci_device *dev = NULL;
> + int error = 0;
> +
> + FOREACH_DEVICE_ON_PCIBUS(dev) {
> + struct rte_pci_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (drv == NULL)
> + continue;
> +
> + ret = drv->remove(dev);
> + if (ret < 0) {
> + rte_errno = errno;
> + error = -1;
> + }
> + }
> +
> + return error;
> +}
> +
> /* dump one device */
> static int
> pci_dump_one_device(FILE *f, struct rte_pci_device *dev)
> @@ -813,6 +836,7 @@ struct rte_pci_bus rte_pci_bus = {
> .bus = {
> .scan = rte_pci_scan,
> .probe = pci_probe,
> + .cleanup = pci_cleanup,
> .find_device = pci_find_device,
> .plug = pci_plug,
> .unplug = pci_unplug,
> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
> index a8d8b2327e..78d6e75b89 100644
> --- a/drivers/bus/vdev/vdev.c
> +++ b/drivers/bus/vdev/vdev.c
> @@ -569,6 +569,29 @@ vdev_probe(void)
> return ret;
> }
>
> +static int
> +vdev_cleanup(void)
> +{
> + struct rte_vdev_device *dev;
> + int error = 0;
> +
> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
> + const char *name;
> + struct rte_vdev_driver *drv;
> + int ret = 0;
> +
> + name = rte_vdev_device_name(dev);
> + if (vdev_parse(name, &drv))
> + continue;
> +
The vdev_d
Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
Thomas Monjalon writes: > The AltiVec header file is defining "vector", except in C++ build. > The keyword "vector" may conflict easily. > As a rule, it is better to use the alternative keyword "__vector". > > The DPDK header file rte_altivec.h takes care of undefining "vector", > so the applications and dependencies are free to define the name "vector". > > This is a compatibility breakage for applications which were using > the keyword "vector" for its AltiVec meaning. > > Signed-off-by: Thomas Monjalon > --- > doc/guides/rel_notes/release_22_07.rst | 5 + > lib/eal/ppc/include/rte_altivec.h | 7 +++ > 2 files changed, 12 insertions(+) > Acked-by: Ray Kinsella
Re: [RFT v2 1/3] random: add rte_rand_float()
Stephen Hemminger writes:
> The PIE code and other applications can benefit from having a
> fast way to get a random floating point value. This new function
> is equivalent to erand48_r in the standard library.
>
> Signed-off-by: Stephen Hemminger
> ---
> app/test/test_rand_perf.c | 7 +++
> doc/guides/rel_notes/release_22_07.rst | 5 +
> lib/eal/common/rte_random.c| 21 +
> lib/eal/include/rte_random.h | 17 +
> lib/eal/version.map| 1 +
> 5 files changed, 51 insertions(+)
>
> diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
> index fe797ebfa1ca..f3602da5b2d4 100644
> --- a/app/test/test_rand_perf.c
> +++ b/app/test/test_rand_perf.c
> @@ -20,6 +20,7 @@ static volatile uint64_t vsum;
>
> enum rand_type {
> rand_type_64,
> + rand_type_float,
> rand_type_bounded_best_case,
> rand_type_bounded_worst_case
> };
> @@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
> switch (rand_type) {
> case rand_type_64:
> return "Full 64-bit [rte_rand()]";
> + case rand_type_float:
> + return "Floating point [rte_rand_float()]";
> case rand_type_bounded_best_case:
> return "Bounded average best-case [rte_rand_max()]";
> case rand_type_bounded_worst_case:
> @@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
> case rand_type_64:
> sum += rte_rand();
> break;
> + case rand_type_float:
> + sum += rte_rand_float() * UINT64_MAX;
> + break;
> case rand_type_bounded_best_case:
> sum += rte_rand_max(BEST_CASE_BOUND);
> break;
> @@ -83,6 +89,7 @@ test_rand_perf(void)
> printf("Pseudo-random number generation latencies:\n");
>
> test_rand_perf_type(rand_type_64);
> + test_rand_perf_type(rand_type_float);
> test_rand_perf_type(rand_type_bounded_best_case);
> test_rand_perf_type(rand_type_bounded_worst_case);
>
> diff --git a/doc/guides/rel_notes/release_22_07.rst
> b/doc/guides/rel_notes/release_22_07.rst
> index e49cacecefd4..128d4fca85b3 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -104,6 +104,11 @@ New Features
>* ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
>* ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
>
> +* ** Added function get random floating point number.**
> +
> + Added the function ``rte_rand_float()`` to provide a pseudo-random
> + floating point number.
> +
>
> Removed Items
> -
> diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> index 4535cc980cec..024c3c41dc16 100644
> --- a/lib/eal/common/rte_random.c
> +++ b/lib/eal/common/rte_random.c
> @@ -6,6 +6,7 @@
> #include
> #endif
> #include
> +#include
>
> #include
> #include
> @@ -173,6 +174,26 @@ rte_rand_max(uint64_t upper_bound)
> return res;
> }
>
> +double
> +rte_rand_float(void)
> +{
> + struct rte_rand_state *state = __rte_rand_get_state();
> + union ieee754_double u = {
> + .ieee = {
> + .negative = 0,
> + .exponent = IEEE754_DOUBLE_BIAS,
> + },
> + };
> + uint64_t val;
> +
> + /* Take 64 bit random value and put it into the mantissa */
> + val = __rte_rand_lfsr258(state);
> + u.ieee.mantissa0 = val >> 32; /* only 20 bits used */
> + u.ieee.mantissa1 = (uint32_t)val;
> +
> + return u.d - 1.0;
> +}
> +
> static uint64_t
> __rte_random_initial_seed(void)
> {
> diff --git a/lib/eal/include/rte_random.h b/lib/eal/include/rte_random.h
> index 29f5f1325a30..553beb2d9c6f 100644
> --- a/lib/eal/include/rte_random.h
> +++ b/lib/eal/include/rte_random.h
> @@ -65,6 +65,23 @@ rte_rand(void);
> uint64_t
> rte_rand_max(uint64_t upper_bound);
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Generates a pseudo-random floating point number.
> + *
> + * This function returns a nonnegative double-precison floating random
> + * number uniformly distributed over the interval [0.0, 1.0).
> + *
> + * If called from lcore threads, this function is thread-safe.
> + *
> + * @return
> + * A pseudo-random value between 0 and 1.0.
> + */
> +__rte_experimental
> +double rte_rand_float(void);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/eal/version.map b/lib/eal/version.map
> index d49e30bd042f..861906af2999 100644
> --- a/lib/eal/version.map
> +++ b/lib/eal/version.map
> @@ -422,6 +422,7 @@ EXPERIMENTAL {
> rte_intr_type_set;
>
> # added in 22.07
> +rte_rand_float;
Niggle - is there an alignment issue on the line above?
> rte_thread_get_affinity_by_id;
> rte_thread_self;
> rte_thread_set_affinity_by_id;
--
Regards, Ray K
Re: [PATCH v8 4/5] ethdev: format module EEPROM for SFF-8472
On 5/25/22 06:14, Robin Zhang wrote:
This patch implements format module EEPROM information for
SFF-8472 Rev 12.0
Signed-off-by: Robin Zhang
[snip]
diff --git a/lib/ethdev/sff_8472.c b/lib/ethdev/sff_8472.c
new file mode 100644
index 00..98e31e9262
--- /dev/null
+++ b/lib/ethdev/sff_8472.c
@@ -0,0 +1,286 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8472 optics diagnostics.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "sff_common.h"
+#include "ethdev_sff_telemetry.h"
Please, fix includes in accordance with previous patches
review notes.
+
+/* Offsets in decimal, for direct comparison with the SFF specs */
+
+/* A0-based EEPROM offsets for DOM support checks */
+#define SFF_A0_DOM92
+#define SFF_A0_OPTIONS93
+#define SFF_A0_COMP 94
+
+/* EEPROM bit values for various registers */
+#define SFF_A0_DOM_EXTCAL (1 << 4)
+#define SFF_A0_DOM_INTCAL (1 << 5)
+#define SFF_A0_DOM_IMPL (1 << 6)
+#define SFF_A0_DOM_PWRT (1 << 3)
+
+#define SFF_A0_OPTIONS_AW (1 << 7)
RTE_BIT32 ?
+
+/*
+ * This is the offset at which the A2 page is in the EEPROM
+ * blob returned by the kernel.
+ */
+#define SFF_A2_BASE 0x100
+
+/* A2-based offsets for DOM */
+#define SFF_A2_TEMP 96
+#define SFF_A2_TEMP_HALRM 0
+#define SFF_A2_TEMP_LALRM 2
+#define SFF_A2_TEMP_HWARN 4
+#define SFF_A2_TEMP_LWARN 6
+
+#define SFF_A2_VCC98
+#define SFF_A2_VCC_HALRM 8
+#define SFF_A2_VCC_LALRM 10
+#define SFF_A2_VCC_HWARN 12
+#define SFF_A2_VCC_LWARN 14
+
+#define SFF_A2_BIAS 100
+#define SFF_A2_BIAS_HALRM 16
+#define SFF_A2_BIAS_LALRM 18
+#define SFF_A2_BIAS_HWARN 20
+#define SFF_A2_BIAS_LWARN 22
+
+#define SFF_A2_TX_PWR 102
+#define SFF_A2_TX_PWR_HALRM 24
+#define SFF_A2_TX_PWR_LALRM 26
+#define SFF_A2_TX_PWR_HWARN 28
+#define SFF_A2_TX_PWR_LWARN 30
+
+#define SFF_A2_RX_PWR 104
+#define SFF_A2_RX_PWR_HALRM 32
+#define SFF_A2_RX_PWR_LALRM 34
+#define SFF_A2_RX_PWR_HWARN 36
+#define SFF_A2_RX_PWR_LWARN 38
+
+#define SFF_A2_ALRM_FLG 112
+#define SFF_A2_WARN_FLG 116
+
+/* 32-bit little-endian calibration constants */
+#define SFF_A2_CAL_RXPWR4 56
+#define SFF_A2_CAL_RXPWR3 60
+#define SFF_A2_CAL_RXPWR2 64
+#define SFF_A2_CAL_RXPWR1 68
+#define SFF_A2_CAL_RXPWR0 72
+
+/* 16-bit little endian calibration constants */
+#define SFF_A2_CAL_TXI_SLP76
+#define SFF_A2_CAL_TXI_OFF78
+#define SFF_A2_CAL_TXPWR_SLP 80
+#define SFF_A2_CAL_TXPWR_OFF 82
+#define SFF_A2_CAL_T_SLP 84
+#define SFF_A2_CAL_T_OFF 86
+#define SFF_A2_CAL_V_SLP 88
+#define SFF_A2_CAL_V_OFF 90
+
+static struct sff_8472_aw_flags {
+ const char *str;/* Human-readable string, null at the end */
+ int offset; /* A2-relative address offset */
+ uint8_t value; /* Alarm is on if (offset & value) != 0. */
+} sff_8472_aw_flags[] = {
+ { "Laser bias current high alarm", SFF_A2_ALRM_FLG, (1 << 3) },
RTE_BIT32 here and below?
+ { "Laser bias current low alarm",SFF_A2_ALRM_FLG, (1 << 2) },
+ { "Laser bias current high warning", SFF_A2_WARN_FLG, (1 << 3) },
+ { "Laser bias current low warning", SFF_A2_WARN_FLG, (1 << 2) },
+
+ { "Laser output power high alarm", SFF_A2_ALRM_FLG, (1 << 1) },
+ { "Laser output power low alarm",SFF_A2_ALRM_FLG, (1 << 0) },
+ { "Laser output power high warning", SFF_A2_WARN_FLG, (1 << 1) },
+ { "Laser output power low warning", SFF_A2_WARN_FLG, (1 << 0) },
+
+ { "Module temperature high alarm", SFF_A2_ALRM_FLG, (1 << 7) },
+ { "Module temperature low alarm",SFF_A2_ALRM_FLG, (1 << 6) },
+ { "Module temperature high warning", SFF_A2_WARN_FLG, (1 << 7) },
+ { "Module temperature low warning", SFF_A2_WARN_FLG, (1 << 6) },
+
+ { "Module voltage high alarm", SFF_A2_ALRM_FLG, (1 << 5) },
+ { "Module voltage low alarm",SFF_A2_ALRM_FLG, (1 << 4) },
+ { "Module voltage high warning", SFF_A2_WARN_FLG, (1 << 5) },
+ { "Module voltage low warning", SFF_A2_WARN_FLG, (1 << 4) },
+
+ { "Laser rx power high alarm", SFF_A2_ALRM_FLG + 1, (1 << 7) },
+ { "Laser rx power low alarm",SFF_A2_
Re: [PATCH v8 5/5] ethdev: format module EEPROM for SFF-8636
On 5/25/22 06:14, Robin Zhang wrote: This patch implements format module EEPROM information for SFF-8636 Rev 2.7 Signed-off-by: Robin Zhang [snip] diff --git a/lib/ethdev/sff_8636.c b/lib/ethdev/sff_8636.c new file mode 100644 index 00..ad625fc73b --- /dev/null +++ b/lib/ethdev/sff_8636.c @@ -0,0 +1,750 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2022 Intel Corporation + * + * Implements SFF-8636 based QSFP+/QSFP28 Diagnostics Memory map. + * + */ + +#include +#include +#include +#include +#include +#include "sff_common.h" +#include "sff_8636.h" +#include "ethdev_sff_telemetry.h" Please, fix includes +/* Flat Memory:0- Paging, 1- Page 0 only */ +#defineSFF_8636_STATUS_PAGE_3_PRESENT (1 << 2) RTE_BIT32 here and in many cases below?
RE: [PATCH] test/crypto-perf: allow auth generate followed by encryption
> Allowing auth generation followed by encryption mode. > --optype auth-then-cipher can take cipher-op as encrypt > and auth-op as generate now. > > Signed-off-by: Tejasree Kondoj Acked-by: Akhil Goyal
RE: [PATCH v2 1/1] app/testpmd: support different input color method
> -Original Message- > From: sk...@marvell.com > Sent: Tuesday, May 24, 2022 8:36 AM > To: Li, Xiaoyun ; Singh, Aman Deep > ; Zhang, Yuying ; > Dumitrescu, Cristian > Cc: dev@dpdk.org; Sunil Kumar Kori > Subject: [PATCH v2 1/1] app/testpmd: support different input color method > > From: Sunil Kumar Kori > > To enable input coloring, based on VLAN or DSCP, patch adds > command line interface to configure the following: > > - configuring input coloring using VLAN or DSCP while creating >meter i.e. during rte_mtr_create() > > - Update VLAN input coloring table at runtime. > > - configures protocol priorities. > > - retrieve protocol and priority information > > Signed-off-by: Sunil Kumar Kori > --- Sunil, Please send a V2 with the "Depends on: " properly set to indicate that Jerin's patch needs to be apply first in order to avoid patch apply failure. Regards, Cristian
Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
On 5/24/22 11:18, Thomas Monjalon wrote:
24/05/2022 04:50, Spike Du:
From: Thomas Monjalon
23/05/2022 05:01, Spike Du:
From: Stephen Hemminger
Spike Du wrote:
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
*/
union rte_eth_rxseg *rx_seg;
- uint64_t reserved_64s[2]; /**< Reserved for future fields */
+ /**
+ * Per-queue Rx limit watermark defined as percentage of Rx queue
+ * size. If Rx queue receives traffic higher than this percentage,
+ * the event RTE_ETH_EVENT_RX_LWM is triggered.
+ */
+ uint8_t lwm;
+
+ uint8_t reserved_bits[3];
+ uint32_t reserved_32s;
+ uint64_t reserved_64s;
Ok but, this is an ABI risk about this because reserved stuff was
never required before.
An ABI compatibility issue would be for an application compiled with an old
DPDK, and loading a new DPDK at runtime.
Let's think what would happen in such a case.
Whenever is a reserved field is introduced the code (in this case
rte_ethdev_configure).
rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
Then the library and drivers may interpret a wrong value.
Best practice would have been to have the code require all reserved
fields be
0 in earlier releases. In this case an application is like to define
a watermark of zero; how will your code handle it.
Having watermark of 0 is desired, which is the default. LWM of 0 means
the Rx Queue's watermark is not monitored, hence no LWM event is
generated.
The problem is to have a value not initialized.
I think the best approach is to not expose the LWM value through this
configuration structure.
If the need is to get the current value, we should better add a field in the
struct rte_eth_rxq_info.
At least from all the dpdk app/example code, rxconf is initialized to 0 then
setup
The Rx queue, if user follows these examples we should not have ABI issue.
Since many people are concerned about rxconf change, it's ok to remove the LWM
Field there.
Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's
attribute,
We should have a way to get it.
Unfortunately we cannot rely on examples for ABI compatibility.
My suggestion of moving the field in rte_eth_rxq_info
is not obvious because it could change the size of the struct.
But thanks to __rte_cache_min_aligned, it is OK.
Running pahole on this struct shows we have 50 bytes free:
/* size: 128, cachelines: 2, members: 6 */
/* padding: 50 */
The other option would be to get the LWM value with a "get" function.
What others prefer?
If I'm not mistaken the changeset breaks ABI in any case since
it adds a new event and changes MAX. If so, I'd wait for the
next ABI breaking release and do not touch reserved fields.
RE: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
> -Original Message- > From: Morten Brørup > Sent: Wednesday, May 25, 2022 3:00 AM > To: NBU-Contact-Thomas Monjalon (EXTERNAL) ; > Spike Du > Cc: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; dev@dpdk.org; > Raslan Darawsheh ; step...@networkplumber.org; > andrew.rybche...@oktetlabs.ru; ferruh.yi...@amd.com; > david.march...@redhat.com > Subject: RE: [PATCH v3 0/7] introduce per-queue limit watermark and host > shaper > > External email: Use caution opening links or attachments > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Tuesday, 24 May 2022 17.59 > > > > +Cc people involved in previous versions > > > > 24/05/2022 17:20, Spike Du: > > > LWM(limit watermark) is per RX queue attribute, when RX queue > > fullness reach the LWM limit, HW sends an event to dpdk application. > > > Host shaper can configure shaper rate and lwm-triggered for a host > > port. > > Please ignore this comment, it is not important, but I had to get it out of my > system: I assume that the "LWM" name is from the NIC datasheet; otherwise > I would probably prefer something with "threshold"... LWM is easily > confused with "low water mark", which is the opposite of what the LWM > does. Names are always open for discussion, so I won't object to it. > > > > The shaper limits the rate of traffic from host port to wire port. > > From host to wire? It is RX, so you must mean from wire to host. The host shaper is quite private to Nvidia's BlueField 2 NIC. The NIC is inserted In a server which we call it host-system, and the NIC has an embedded Arm-system Which does the forwarding. The traffic flows from host-system to wire like this: Host-system generates traffic, send it to Arm-system, Arm sends it to physical/wire port. So the RX happens between host-system and Arm-system, and the traffic is host to wire. The shaper also works in a special way: you configure it on Arm-system, but it takes effect On host-sysmem's TX side. > > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled > > automatically when one of the host port's Rx queues receives LWM event. > > > > > > These two features can combine to control traffic from host port to > > wire port. > > Again, you mean from wire to host? Pls see above. > > > > The work flow is configure LWM to RX queue and enable lwm-triggered > > flag in host shaper, after receiving LWM event, delay a while until RX > > queue is empty , then disable the shaper. We recycle this work flow to > > reduce RX queue drops. > > You delay while RX queue gets drained by some other threads, I assume. The PMD thread drains the Rx queue, the PMD receiving as normal, as the PMD Implementation uses rte interrupt thread to handle LWM event. > > Surely, the excess packets must be dropped somewhere, e.g. by the shaper? > > > > > > > Add new libethdev API to set LWM, add rte event > > RTE_ETH_EVENT_RXQ_LIMIT_REACHED to handle LWM event. > > Makes sense to make it public; could be usable for other purposes, similar to > interrupt coalescing, as mentioned by Stephen. > > > > For host shaper, > > because it doesn't align to existing DPDK framework and is specific to > > Nvidia NIC, use PMD private API. > > Makes sense to keep it private. > > > > > > > For integration with testpmd, put the private cmdline function and > > LWM event handler in mlx5 PMD directory by adding a new file > > mlx5_test.c. Only add minimal code in testpmd to invoke interfaces > > from mlx5_test.c. > > > > > > Spike Du (7): > > > net/mlx5: add LWM support for Rxq > > > common/mlx5: share interrupt management > > > ethdev: introduce Rx queue based limit watermark > > > net/mlx5: add LWM event handling support > > > net/mlx5: support Rx queue based limit watermark > > > net/mlx5: add private API to config host port shaper > > > app/testpmd: add LWM and Host Shaper command > > >
Re: [PATCH v5 5/5] baseband/acc100: configuration of ACC101 from PF
Hi Nicolas,
On 5/24/22 02:08, Nicolas Chautru wrote:
Adding companion function specific to ACC100 and it
can be called from bbdev-test when running from PF.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_perf.c | 22 ++-
drivers/baseband/acc100/rte_acc100_cfg.h | 17 ++
drivers/baseband/acc100/rte_acc100_pmd.c | 302 +++
drivers/baseband/acc100/version.map | 2 +-
4 files changed, 336 insertions(+), 7 deletions(-)
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 0fa119a..89b1e79 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -63,6 +63,8 @@
#define ACC100_QMGR_INVALID_IDX -1
#define ACC100_QMGR_RR 1
#define ACC100_QOS_GBR 0
+#define ACC101PF_DRIVER_NAME ("intel_acc101_pf")
+#define ACC101VF_DRIVER_NAME ("intel_acc101_vf")
#endif
#define OPS_CACHE_SIZE 256U
@@ -711,11 +713,12 @@ typedef int (test_case_function)(struct active_device *ad,
#endif
#ifdef RTE_BASEBAND_ACC100
if ((get_init_device() == true) &&
- (!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME))) {
+ ((!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME))
||
+ (!strcmp(info->drv.driver_name,
ACC101PF_DRIVER_NAME {
struct rte_acc100_conf conf;
unsigned int i;
- printf("Configure ACC100 FEC Driver %s with default values\n",
+ printf("Configure ACC100/ACC101 FEC Driver %s with default
values\n",
info->drv.driver_name);
/* clear default configuration before initialization */
@@ -760,10 +763,17 @@ typedef int (test_case_function)(struct active_device *ad,
conf.q_dl_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
/* setup PF with configuration information */
- ret = rte_acc100_configure(info->dev_name, &conf);
- TEST_ASSERT_SUCCESS(ret,
- "Failed to configure ACC100 PF for bbdev %s",
- info->dev_name);
+ if (!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME)) {
+ ret = rte_acc100_configure(info->dev_name, &conf);
+ TEST_ASSERT_SUCCESS(ret,
+ "Failed to configure ACC100 PF for bbdev
%s",
+ info->dev_name);
+ } else {
+ ret = rte_acc101_configure(info->dev_name, &conf);
+ TEST_ASSERT_SUCCESS(ret,
+ "Failed to configure ACC101 PF for bbdev
%s",
+ info->dev_name);
+ }
Having a single function for configuration, and a single driver would
avoid this.
You can keep the rte_acc100_configure and rte_acc100_configure functions
almost unmodified, just remove rte_ prefix and remove them from exported
API. Then introduce a rte_acc10x_configure which call proper
configuration function based on device ID.
}
#endif
/* Let's refresh this now this is configured */
diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h
b/drivers/baseband/acc100/rte_acc100_cfg.h
index d233e42..2e3c43f 100644
--- a/drivers/baseband/acc100/rte_acc100_cfg.h
+++ b/drivers/baseband/acc100/rte_acc100_cfg.h
@@ -106,6 +106,23 @@ struct rte_acc100_conf {
int
rte_acc100_configure(const char *dev_name, struct rte_acc100_conf *conf);
+/**
+ * Configure a ACC101 device
+ *
+ * @param dev_name
+ * The name of the device. This is the short form of PCI BDF, e.g. 00:01.0.
+ * It can also be retrieved for a bbdev device from the dev_name field in the
+ * rte_bbdev_info structure returned by rte_bbdev_info_get().
+ * @param conf
+ * Configuration to apply to ACC101 HW.
+ *
+ * @return
+ * Zero on success, negative value on failure.
+ */
+__rte_experimental
+int
+rte_acc101_configure(const char *dev_name, struct rte_acc100_conf *conf);
+
#ifdef __cplusplus
}
#endif
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index e3706e0..78c45d2 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -5005,3 +5005,305 @@ static int acc100_pci_remove(struct rte_pci_device
*pci_dev)
rte_bbdev_log_debug("PF Tip configuration complete for %s", dev_name);
return 0;
}
+
+
+/* Initial configuration of a ACC101 device prior to running configure() */
+int
+rte_acc101_configure(const char *dev_name, struct rte_acc100_conf *conf)
+{
+ rte_bbdev_log(INFO, "rte_acc101_configure");
+ uint32_t value, address, status;
+ int qg_idx, template_idx, vf_idx, acc, i;
+ struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
+
+ /* Compile time checks */
+ RTE_BUILD_BUG_ON(sizeof(struct acc100_dma_req_desc) != 256);
+
RE: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
> From: Spike Du [mailto:spi...@nvidia.com] > Sent: Wednesday, 25 May 2022 15.15 > > > From: Morten Brørup > > Sent: Wednesday, May 25, 2022 3:00 AM > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > Sent: Tuesday, 24 May 2022 17.59 > > > > > > +Cc people involved in previous versions > > > > > > 24/05/2022 17:20, Spike Du: > > > > LWM(limit watermark) is per RX queue attribute, when RX queue > > > fullness reach the LWM limit, HW sends an event to dpdk > application. > > > > Host shaper can configure shaper rate and lwm-triggered for a > host > > > port. > > > > Please ignore this comment, it is not important, but I had to get it > out of my > > system: I assume that the "LWM" name is from the NIC datasheet; > otherwise > > I would probably prefer something with "threshold"... LWM is easily > > confused with "low water mark", which is the opposite of what the LWM > > does. Names are always open for discussion, so I won't object to it. > > > > > > The shaper limits the rate of traffic from host port to wire > port. > > > > From host to wire? It is RX, so you must mean from wire to host. > > The host shaper is quite private to Nvidia's BlueField 2 NIC. The NIC > is inserted > In a server which we call it host-system, and the NIC has an embedded > Arm-system > Which does the forwarding. > The traffic flows from host-system to wire like this: > Host-system generates traffic, send it to Arm-system, Arm sends it to > physical/wire port. > So the RX happens between host-system and Arm-system, and the traffic > is host to wire. > The shaper also works in a special way: you configure it on Arm-system, > but it takes effect > On host-sysmem's TX side. > > > > > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled > > > automatically when one of the host port's Rx queues receives LWM > event. > > > > > > > > These two features can combine to control traffic from host port > to > > > wire port. > > > > Again, you mean from wire to host? > > Pls see above. > > > > > > > The work flow is configure LWM to RX queue and enable lwm- > triggered > > > flag in host shaper, after receiving LWM event, delay a while until > RX > > > queue is empty , then disable the shaper. We recycle this work flow > to > > > reduce RX queue drops. > > > > You delay while RX queue gets drained by some other threads, I > assume. > > The PMD thread drains the Rx queue, the PMD receiving as normal, as > the PMD > Implementation uses rte interrupt thread to handle LWM event. > Thank you for the explanation, Spike. It really clarifies a lot! If this patch is intended for DPDK running on the host-system, then the LWM attribute is associated with a TX queue, not an RX queue. The packets are egressing from the host-system, so TX from the host-system's perspective. Otherwise, if this patch is for DPDK running on the embedded ARM-system, it should be highlighted somewhere. > > > > Surely, the excess packets must be dropped somewhere, e.g. by the > shaper? I guess the shaper doesn't have to drop any packets, but the host-system will simply be unable to put more packets into the queue if it runs full.
Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
25/05/2022 14:59, Andrew Rybchenko:
> On 5/24/22 11:18, Thomas Monjalon wrote:
> > 24/05/2022 04:50, Spike Du:
> >> From: Thomas Monjalon
> >>> 23/05/2022 05:01, Spike Du:
> From: Stephen Hemminger
> > Spike Du wrote:
> >> --- a/lib/ethdev/rte_ethdev.h
> >> +++ b/lib/ethdev/rte_ethdev.h
> >> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> >> */
> >>union rte_eth_rxseg *rx_seg;
> >>
> >> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> >> + /**
> >> + * Per-queue Rx limit watermark defined as percentage of Rx queue
> >> + * size. If Rx queue receives traffic higher than this
> >> percentage,
> >> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> >> + */
> >> + uint8_t lwm;
> >> +
> >> + uint8_t reserved_bits[3];
> >> + uint32_t reserved_32s;
> >> + uint64_t reserved_64s;
> >
> > Ok but, this is an ABI risk about this because reserved stuff was
> > never required before.
> >>>
> >>> An ABI compatibility issue would be for an application compiled with an
> >>> old
> >>> DPDK, and loading a new DPDK at runtime.
> >>> Let's think what would happen in such a case.
> >>>
> > Whenever is a reserved field is introduced the code (in this case
> > rte_ethdev_configure).
> >>>
> >>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> >>> Then the library and drivers may interpret a wrong value.
> >>>
> > Best practice would have been to have the code require all reserved
> > fields be
> > 0 in earlier releases. In this case an application is like to define
> > a watermark of zero; how will your code handle it.
>
> Having watermark of 0 is desired, which is the default. LWM of 0 means
> the Rx Queue's watermark is not monitored, hence no LWM event is
> >>> generated.
> >>>
> >>> The problem is to have a value not initialized.
> >>> I think the best approach is to not expose the LWM value through this
> >>> configuration structure.
> >>> If the need is to get the current value, we should better add a field in
> >>> the
> >>> struct rte_eth_rxq_info.
> >>
> >> At least from all the dpdk app/example code, rxconf is initialized to 0
> >> then setup
> >> The Rx queue, if user follows these examples we should not have ABI issue.
> >> Since many people are concerned about rxconf change, it's ok to remove the
> >> LWM
> >> Field there.
> >> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx
> >> queue's attribute,
> >> We should have a way to get it.
> >
> > Unfortunately we cannot rely on examples for ABI compatibility.
> > My suggestion of moving the field in rte_eth_rxq_info
> > is not obvious because it could change the size of the struct.
> > But thanks to __rte_cache_min_aligned, it is OK.
> > Running pahole on this struct shows we have 50 bytes free:
> > /* size: 128, cachelines: 2, members: 6 */
> > /* padding: 50 */
> >
> > The other option would be to get the LWM value with a "get" function.
> >
> > What others prefer?
>
> If I'm not mistaken the changeset breaks ABI in any case since
> it adds a new event and changes MAX.
I think we can consider it as not a breakage (a rule should be added).
Last time we had to update this enum, this was the conclusion:
from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
"
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered
In general, it is safe adding new ethdev event types at the end of the
enum, because of event callback registration mechanism.
"
> If so, I'd wait for the
> next ABI breaking release and do not touch reserved fields.
In any case, rte_eth_rxconf is not a good fit
because we have a separate function for configuration.
It should be either in rte_eth_rxq_info or a specific "get" function.
[PATCH 1/3] ipsec: fix NAT-T ports and length
Fix the UDP header fields, wrong byte order used for src and dst port
and wrong offset used when updating UDP datagram length.
Fixes: 01eef5907fc3 ("ipsec: support NAT-T")
Cc: sta...@dpdk.org
Signed-off-by: Radu Nicolau
---
lib/ipsec/esp_outb.c | 2 +-
lib/ipsec/sa.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ipsec/esp_outb.c b/lib/ipsec/esp_outb.c
index 6925bb9945..5a5429a12b 100644
--- a/lib/ipsec/esp_outb.c
+++ b/lib/ipsec/esp_outb.c
@@ -196,7 +196,7 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t
sqc,
/* if UDP encap is enabled update the dgram_len */
if (sa->type & RTE_IPSEC_SATP_NATT_ENABLE) {
struct rte_udp_hdr *udph = (struct rte_udp_hdr *)
- (ph - sizeof(struct rte_udp_hdr));
+ (ph + sa->hdr_len - sizeof(struct rte_udp_hdr));
udph->dgram_len = rte_cpu_to_be_16(mb->pkt_len - sqh_len -
sa->hdr_l3_off - sa->hdr_len);
}
diff --git a/lib/ipsec/sa.c b/lib/ipsec/sa.c
index 1b673b6a18..59a547637d 100644
--- a/lib/ipsec/sa.c
+++ b/lib/ipsec/sa.c
@@ -364,8 +364,8 @@ esp_outb_tun_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm)
struct rte_udp_hdr *udph = (struct rte_udp_hdr *)
&sa->hdr[prm->tun.hdr_len];
sa->hdr_len += sizeof(struct rte_udp_hdr);
- udph->src_port = prm->ipsec_xform.udp.sport;
- udph->dst_port = prm->ipsec_xform.udp.dport;
+ udph->src_port = rte_cpu_to_be_16(prm->ipsec_xform.udp.sport);
+ udph->dst_port = rte_cpu_to_be_16(prm->ipsec_xform.udp.dport);
udph->dgram_cksum = 0;
}
--
2.25.1
[PATCH 2/3] examples/ipsec-secgw: fix NAT-T header fields
Use the proper IP protocol (UDP instead of ESP) and set the ports when
UDP encapsulation is enabled.
Fixes: 9ae86b4cfc77 ("examples/ipsec-secgw: support UDP encap for inline
crypto")
Cc: sta...@dpdk.org
Signed-off-by: Radu Nicolau
---
examples/ipsec-secgw/sa.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 1839ac71af..45509c5c68 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1458,6 +1458,8 @@ fill_ipsec_sa_prm(struct rte_ipsec_sa_prm *prm, const
struct ipsec_sa *ss,
RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT :
RTE_SECURITY_IPSEC_SA_MODE_TUNNEL;
prm->ipsec_xform.options.udp_encap = ss->udp_encap;
+ prm->ipsec_xform.udp.dport = ss->udp.dport;
+ prm->ipsec_xform.udp.sport = ss->udp.sport;
prm->ipsec_xform.options.ecn = 1;
prm->ipsec_xform.options.copy_dscp = 1;
@@ -1513,13 +1515,13 @@ ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa
*sa, uint32_t sa_size)
.version_ihl = IPVERSION << 4 |
sizeof(v4) / RTE_IPV4_IHL_MULTIPLIER,
.time_to_live = IPDEFTTL,
- .next_proto_id = IPPROTO_ESP,
+ .next_proto_id = lsa->udp_encap ? IPPROTO_UDP : IPPROTO_ESP,
.src_addr = lsa->src.ip.ip4,
.dst_addr = lsa->dst.ip.ip4,
};
struct rte_ipv6_hdr v6 = {
.vtc_flow = htonl(IP6_VERSION << 28),
- .proto = IPPROTO_ESP,
+ .proto = lsa->udp_encap ? IPPROTO_UDP : IPPROTO_ESP,
};
if (IS_IP6_TUNNEL(lsa->flags)) {
--
2.25.1
[PATCH 3/3] net/iavf: fix NAT-T payload length
Correct the length calculation used for NAT-T
Fixes: 6bc987ecb860 ("net/iavf: support IPsec inline crypto")
Cc: sta...@dpdk.org
Signed-off-by: Radu Nicolau
---
drivers/net/iavf/iavf_ipsec_crypto.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/iavf/iavf_ipsec_crypto.c
b/drivers/net/iavf/iavf_ipsec_crypto.c
index b1949cee91..b398819096 100644
--- a/drivers/net/iavf/iavf_ipsec_crypto.c
+++ b/drivers/net/iavf/iavf_ipsec_crypto.c
@@ -1118,11 +1118,14 @@ iavf_ipsec_crypto_compute_l4_payload_length(struct
rte_mbuf *m,
* ipv4/6 hdr + ext hdrs
*/
- if (s->udp_encap.enabled)
+ if (s->udp_encap.enabled) {
ol4_len = sizeof(struct rte_udp_hdr);
-
- l3_len = m->l3_len;
- l4_len = m->l4_len;
+ l3_len = m->l3_len - ol4_len;
+ l4_len = l3_len;
+ } else {
+ l3_len = m->l3_len;
+ l4_len = m->l4_len;
+ }
return rte_pktmbuf_pkt_len(m) - (ol2_len + ol3_len + ol4_len +
esp_hlen + l3_len + l4_len + esp_tlen);
--
2.25.1
RE: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
> -Original Message- > From: Morten Brørup > Sent: Wednesday, May 25, 2022 9:40 PM > To: Spike Du ; NBU-Contact-Thomas Monjalon > (EXTERNAL) > Cc: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; dev@dpdk.org; > Raslan Darawsheh ; step...@networkplumber.org; > andrew.rybche...@oktetlabs.ru; ferruh.yi...@amd.com; > david.march...@redhat.com > Subject: RE: [PATCH v3 0/7] introduce per-queue limit watermark and host > shaper > > External email: Use caution opening links or attachments > > > > From: Spike Du [mailto:spi...@nvidia.com] > > Sent: Wednesday, 25 May 2022 15.15 > > > > > From: Morten Brørup > > > Sent: Wednesday, May 25, 2022 3:00 AM > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > Sent: Tuesday, 24 May 2022 17.59 > > > > > > > > +Cc people involved in previous versions > > > > > > > > 24/05/2022 17:20, Spike Du: > > > > > LWM(limit watermark) is per RX queue attribute, when RX queue > > > > fullness reach the LWM limit, HW sends an event to dpdk > > application. > > > > > Host shaper can configure shaper rate and lwm-triggered for a > > host > > > > port. > > > > > > Please ignore this comment, it is not important, but I had to get it > > out of my > > > system: I assume that the "LWM" name is from the NIC datasheet; > > otherwise > > > I would probably prefer something with "threshold"... LWM is easily > > > confused with "low water mark", which is the opposite of what the > > > LWM does. Names are always open for discussion, so I won't object to it. > > > > > > > > The shaper limits the rate of traffic from host port to wire > > port. > > > > > > From host to wire? It is RX, so you must mean from wire to host. > > > > The host shaper is quite private to Nvidia's BlueField 2 NIC. The NIC > > is inserted In a server which we call it host-system, and the NIC has > > an embedded Arm-system Which does the forwarding. > > The traffic flows from host-system to wire like this: > > Host-system generates traffic, send it to Arm-system, Arm sends it to > > physical/wire port. > > So the RX happens between host-system and Arm-system, and the traffic > > is host to wire. > > The shaper also works in a special way: you configure it on > > Arm-system, but it takes effect On host-sysmem's TX side. > > > > > > > > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled > > > > automatically when one of the host port's Rx queues receives LWM > > event. > > > > > > > > > > These two features can combine to control traffic from host port > > to > > > > wire port. > > > > > > Again, you mean from wire to host? > > > > Pls see above. > > > > > > > > > > The work flow is configure LWM to RX queue and enable lwm- > > triggered > > > > flag in host shaper, after receiving LWM event, delay a while > > > > until > > RX > > > > queue is empty , then disable the shaper. We recycle this work > > > > flow > > to > > > > reduce RX queue drops. > > > > > > You delay while RX queue gets drained by some other threads, I > > assume. > > > > The PMD thread drains the Rx queue, the PMD receiving as normal, as > > the PMD Implementation uses rte interrupt thread to handle LWM event. > > > > Thank you for the explanation, Spike. It really clarifies a lot! > > If this patch is intended for DPDK running on the host-system, then the LWM > attribute is associated with a TX queue, not an RX queue. The packets are > egressing from the host-system, so TX from the host-system's perspective. > > Otherwise, if this patch is for DPDK running on the embedded ARM-system, > it should be highlighted somewhere. The host-shaper patch is running on ARM-system, I think in that patch I have some explanation in mlx5.rst. The LWM patch is common and should work on any Rx queue(right now mlx5 doesn't support Hairpin Rx queue and shared Rx queue). On ARM-system, we can use it to monitor traffic from host(representor port) or from wire(physical port). LWM can also work on host-system if there is DPDK running, for example it can monitor traffic from Arm-system to host-system. > > > > > > > Surely, the excess packets must be dropped somewhere, e.g. by the > > shaper? > > I guess the shaper doesn't have to drop any packets, but the host-system will > simply be unable to put more packets into the queue if it runs full. > When LWM event happens, the host-shaper throttles traffic from host-system to Arm-system. Yes, the shaper doesn't drop pkts. Normally the shaper is small and if PMD thread on Arm keeps working, Rx queue is dropless. But if PMD thread doesn't receive fast enough, or even with a small shaper but host-system is sending some burst, Rx queue may still drop on Arm. Anyway even sometimes drop still happens, the cooperation of host-shaper and LWM greatly reduce the Rx drop on Arm.
Re: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
On 5/24/22 22:22, Thomas Monjalon wrote: 24/05/2022 21:00, Morten Brørup: From: Thomas Monjalon [mailto:tho...@monjalon.net] 24/05/2022 17:20, Spike Du: LWM(limit watermark) is per RX queue attribute, when RX queue fullness reach the LWM limit, HW sends an event to dpdk application. Please ignore this comment, it is not important, but I had to get it out of my system: I assume that the "LWM" name is from the NIC datasheet; otherwise I would probably prefer something with "threshold"... LWM is easily confused with "low water mark", which is the opposite of what the LWM does. Names are always open for discussion, so I won't object to it. Yes it is a threshold, and yes it is often called a watermark. I think we can get more ideas and votes about the naming. Please let's conclude on a short name which can be inserted easily in function names. As I understand it is an Rx queue fill (level) threshold. "fill_thresh" or "flt" if the first one is too long.
RE: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
> From: Spike Du [mailto:spi...@nvidia.com] > Sent: Wednesday, 25 May 2022 15.59 > > > From: Morten Brørup > > Sent: Wednesday, May 25, 2022 9:40 PM > > > > > From: Spike Du [mailto:spi...@nvidia.com] > > > Sent: Wednesday, 25 May 2022 15.15 > > > > > > > From: Morten Brørup > > > > Sent: Wednesday, May 25, 2022 3:00 AM > > > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > Sent: Tuesday, 24 May 2022 17.59 > > > > > > > > > > +Cc people involved in previous versions > > > > > > > > > > 24/05/2022 17:20, Spike Du: > > > > > > LWM(limit watermark) is per RX queue attribute, when RX queue > > > > > fullness reach the LWM limit, HW sends an event to dpdk > > > application. > > > > > > Host shaper can configure shaper rate and lwm-triggered for a > > > host > > > > > port. > > > > > > > > > > > > > > The shaper limits the rate of traffic from host port to wire > > > port. > > > > > > > > From host to wire? It is RX, so you must mean from wire to host. > > > > > > The host shaper is quite private to Nvidia's BlueField 2 NIC. The > NIC > > > is inserted In a server which we call it host-system, and the NIC > has > > > an embedded Arm-system Which does the forwarding. > > > The traffic flows from host-system to wire like this: > > > Host-system generates traffic, send it to Arm-system, Arm sends it > to > > > physical/wire port. > > > So the RX happens between host-system and Arm-system, and the > traffic > > > is host to wire. > > > The shaper also works in a special way: you configure it on > > > Arm-system, but it takes effect On host-sysmem's TX side. > > > > > > > > > > > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled > > > > > automatically when one of the host port's Rx queues receives > LWM > > > event. > > > > > > > > > > > > These two features can combine to control traffic from host > port > > > to > > > > > wire port. > > > > > > > > Again, you mean from wire to host? > > > > > > Pls see above. > > > > > > > > > > > > > The work flow is configure LWM to RX queue and enable lwm- > > > triggered > > > > > flag in host shaper, after receiving LWM event, delay a while > > > > > until > > > RX > > > > > queue is empty , then disable the shaper. We recycle this work > > > > > flow > > > to > > > > > reduce RX queue drops. > > > > > > > > You delay while RX queue gets drained by some other threads, I > > > assume. > > > > > > The PMD thread drains the Rx queue, the PMD receiving as normal, > as > > > the PMD Implementation uses rte interrupt thread to handle LWM > event. > > > > > > > Thank you for the explanation, Spike. It really clarifies a lot! > > > > If this patch is intended for DPDK running on the host-system, then > the LWM > > attribute is associated with a TX queue, not an RX queue. The packets > are > > egressing from the host-system, so TX from the host-system's > perspective. > > > > Otherwise, if this patch is for DPDK running on the embedded ARM- > system, > > it should be highlighted somewhere. > > The host-shaper patch is running on ARM-system, I think in that patch I > have some explanation in mlx5.rst. > The LWM patch is common and should work on any Rx queue(right now mlx5 > doesn't support Hairpin Rx queue and shared Rx queue). > On ARM-system, we can use it to monitor traffic from host(representor > port) or from wire(physical port). > LWM can also work on host-system if there is DPDK running, for example > it can monitor traffic from Arm-system to host-system. OK. Then I get it! I was reading the patch description wearing my host-system glasses, and thus got very confused. :-) > > > > > > > > > > > Surely, the excess packets must be dropped somewhere, e.g. by the > > > shaper? > > > > I guess the shaper doesn't have to drop any packets, but the host- > system will > > simply be unable to put more packets into the queue if it runs full. > > > > When LWM event happens, the host-shaper throttles traffic from host- > system to Arm-system. Yes, the shaper doesn't drop pkts. > Normally the shaper is small and if PMD thread on Arm keeps working, Rx > queue is dropless. > But if PMD thread doesn't receive fast enough, or even with a small > shaper but host-system is sending some burst, Rx queue may still drop > on Arm. > Anyway even sometimes drop still happens, the cooperation of host- > shaper and LWM greatly reduce the Rx drop on Arm. Thanks for elaborating. And yes, shapers are excellent for many scenarios.
RE: [PATCH v4] sched: enable traffic class oversubscription conditionally
Hi Cristian, Oh .. you absolutely right. I did not found them all .. I've missed them in all unneeded lines when you reply to full source code in message. I'll add changes from rest of the comments asap. BR, /Marcin -Original Message- From: Dumitrescu, Cristian Sent: Tuesday, May 24, 2022 4:30 PM To: Danilewicz, MarcinX ; dev@dpdk.org; Singh, Jasvinder Cc: Ajmera, Megha ; Thakur, Sham Singh ; Mcnamara, John ; Devlin, Michelle Subject: RE: [PATCH v4] sched: enable traffic class oversubscription conditionally > -Original Message- > From: Danilewicz, MarcinX > Sent: Tuesday, May 24, 2022 2:44 PM > To: dev@dpdk.org; Singh, Jasvinder ; > Dumitrescu, Cristian > Cc: Ajmera, Megha > Subject: [PATCH v4] sched: enable traffic class oversubscription > conditionally > > Added new API to enable or disable TC over subscription for best > effort traffic class at subport level. > Added changes after review and increased throughput. > > By default TC OV is disabled. > History: > - v1 - TC OV disabled by default > - v2 - throughput improvements > - v3, v4 - changes from comments > > Signed-off-by: Marcin Danilewicz > --- > lib/sched/rte_sched.c | 189 +++-- Marcin, I don't see any of my comments on the previous V3 version addressed. You mention in the change log that you addressed comments, but I see that all my comments were silently disregarded. Jasvinder also noted the same for his comments in a previous version. Please address the comments and do not keep sending the same code over and over. This change was supposed to be straightforward, but for some reason the progress is extremely slow on your side. I think at this point we are at risk of missing the RC1 deadline for this feature. Regards, Cristian -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
On 5/25/22 16:58, Thomas Monjalon wrote:
25/05/2022 14:59, Andrew Rybchenko:
On 5/24/22 11:18, Thomas Monjalon wrote:
24/05/2022 04:50, Spike Du:
From: Thomas Monjalon
23/05/2022 05:01, Spike Du:
From: Stephen Hemminger
Spike Du wrote:
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
*/
union rte_eth_rxseg *rx_seg;
- uint64_t reserved_64s[2]; /**< Reserved for future fields */
+ /**
+ * Per-queue Rx limit watermark defined as percentage of Rx queue
+ * size. If Rx queue receives traffic higher than this percentage,
+ * the event RTE_ETH_EVENT_RX_LWM is triggered.
+ */
+ uint8_t lwm;
+
+ uint8_t reserved_bits[3];
+ uint32_t reserved_32s;
+ uint64_t reserved_64s;
Ok but, this is an ABI risk about this because reserved stuff was
never required before.
An ABI compatibility issue would be for an application compiled with an old
DPDK, and loading a new DPDK at runtime.
Let's think what would happen in such a case.
Whenever is a reserved field is introduced the code (in this case
rte_ethdev_configure).
rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
Then the library and drivers may interpret a wrong value.
Best practice would have been to have the code require all reserved
fields be
0 in earlier releases. In this case an application is like to define
a watermark of zero; how will your code handle it.
Having watermark of 0 is desired, which is the default. LWM of 0 means
the Rx Queue's watermark is not monitored, hence no LWM event is
generated.
The problem is to have a value not initialized.
I think the best approach is to not expose the LWM value through this
configuration structure.
If the need is to get the current value, we should better add a field in the
struct rte_eth_rxq_info.
At least from all the dpdk app/example code, rxconf is initialized to 0 then
setup
The Rx queue, if user follows these examples we should not have ABI issue.
Since many people are concerned about rxconf change, it's ok to remove the LWM
Field there.
Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's
attribute,
We should have a way to get it.
Unfortunately we cannot rely on examples for ABI compatibility.
My suggestion of moving the field in rte_eth_rxq_info
is not obvious because it could change the size of the struct.
But thanks to __rte_cache_min_aligned, it is OK.
Running pahole on this struct shows we have 50 bytes free:
/* size: 128, cachelines: 2, members: 6 */
/* padding: 50 */
The other option would be to get the LWM value with a "get" function.
What others prefer?
If I'm not mistaken the changeset breaks ABI in any case since
it adds a new event and changes MAX.
I think we can consider it as not a breakage (a rule should be added).
Last time we had to update this enum, this was the conclusion:
from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
"
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered
In general, it is safe adding new ethdev event types at the end of the
enum, because of event callback registration mechanism.
"
I see. Makes sense. Thanks for the information.
If so, I'd wait for the
next ABI breaking release and do not touch reserved fields.
In any case, rte_eth_rxconf is not a good fit
because we have a separate function for configuration.
Yes, it is better to avoid two ways to configure the same
thing.
It should be either in rte_eth_rxq_info or a specific "get" function.
I see no point to introduce specific get function for a single
value. I think that rte_eth_rxq_info is the right way to get
current value.
Re: [PATCH v3 0/7] introduce per-queue limit watermark and host shaper
On 5/25/22 17:16, Morten Brørup wrote: From: Spike Du [mailto:spi...@nvidia.com] Sent: Wednesday, 25 May 2022 15.59 From: Morten Brørup Sent: Wednesday, May 25, 2022 9:40 PM From: Spike Du [mailto:spi...@nvidia.com] Sent: Wednesday, 25 May 2022 15.15 From: Morten Brørup Sent: Wednesday, May 25, 2022 3:00 AM From: Thomas Monjalon [mailto:tho...@monjalon.net] Sent: Tuesday, 24 May 2022 17.59 +Cc people involved in previous versions 24/05/2022 17:20, Spike Du: LWM(limit watermark) is per RX queue attribute, when RX queue fullness reach the LWM limit, HW sends an event to dpdk application. Host shaper can configure shaper rate and lwm-triggered for a host port. The shaper limits the rate of traffic from host port to wire port. From host to wire? It is RX, so you must mean from wire to host. The host shaper is quite private to Nvidia's BlueField 2 NIC. The NIC is inserted In a server which we call it host-system, and the NIC has an embedded Arm-system Which does the forwarding. The traffic flows from host-system to wire like this: Host-system generates traffic, send it to Arm-system, Arm sends it to physical/wire port. So the RX happens between host-system and Arm-system, and the traffic is host to wire. The shaper also works in a special way: you configure it on Arm-system, but it takes effect On host-sysmem's TX side. If lwm-triggered is enabled, a 100Mbps shaper is enabled automatically when one of the host port's Rx queues receives LWM event. These two features can combine to control traffic from host port to wire port. Again, you mean from wire to host? Pls see above. The work flow is configure LWM to RX queue and enable lwm- triggered flag in host shaper, after receiving LWM event, delay a while until RX queue is empty , then disable the shaper. We recycle this work flow to reduce RX queue drops. You delay while RX queue gets drained by some other threads, I assume. The PMD thread drains the Rx queue, the PMD receiving as normal, as the PMD Implementation uses rte interrupt thread to handle LWM event. Thank you for the explanation, Spike. It really clarifies a lot! If this patch is intended for DPDK running on the host-system, then the LWM attribute is associated with a TX queue, not an RX queue. The packets are egressing from the host-system, so TX from the host-system's perspective. Otherwise, if this patch is for DPDK running on the embedded ARM- system, it should be highlighted somewhere. The host-shaper patch is running on ARM-system, I think in that patch I have some explanation in mlx5.rst. The LWM patch is common and should work on any Rx queue(right now mlx5 doesn't support Hairpin Rx queue and shared Rx queue). On ARM-system, we can use it to monitor traffic from host(representor port) or from wire(physical port). LWM can also work on host-system if there is DPDK running, for example it can monitor traffic from Arm-system to host-system. OK. Then I get it! I was reading the patch description wearing my host-system glasses, and thus got very confused. :-) The description in cover letter is very misleading for me as well. It is not a problem right now after long detailed explanations. Hopefully there is no such problem in suggested ethdev documentation. I'll reread it carefully before applying when time comes. Surely, the excess packets must be dropped somewhere, e.g. by the shaper? I guess the shaper doesn't have to drop any packets, but the host- system will simply be unable to put more packets into the queue if it runs full. When LWM event happens, the host-shaper throttles traffic from host- system to Arm-system. Yes, the shaper doesn't drop pkts. Normally the shaper is small and if PMD thread on Arm keeps working, Rx queue is dropless. But if PMD thread doesn't receive fast enough, or even with a small shaper but host-system is sending some burst, Rx queue may still drop on Arm. Anyway even sometimes drop still happens, the cooperation of host- shaper and LWM greatly reduce the Rx drop on Arm. Thanks for elaborating. And yes, shapers are excellent for many scenarios.
RE: [PATCH v2 1/1] app/testpmd: support different input color method
> -Original Message- > From: Dumitrescu, Cristian > Sent: Wednesday, May 25, 2022 6:07 PM > To: Sunil Kumar Kori ; Li, Xiaoyun > ; Singh, Aman Deep ; > Zhang, Yuying > Cc: dev@dpdk.org > Subject: [EXT] RE: [PATCH v2 1/1] app/testpmd: support different input color > method > > External Email > > -- > > > > -Original Message- > > From: sk...@marvell.com > > Sent: Tuesday, May 24, 2022 8:36 AM > > To: Li, Xiaoyun ; Singh, Aman Deep > > ; Zhang, Yuying ; > > Dumitrescu, Cristian > > Cc: dev@dpdk.org; Sunil Kumar Kori > > Subject: [PATCH v2 1/1] app/testpmd: support different input color > > method > > > > From: Sunil Kumar Kori > > > > To enable input coloring, based on VLAN or DSCP, patch adds command > > line interface to configure the following: > > > > - configuring input coloring using VLAN or DSCP while creating > >meter i.e. during rte_mtr_create() > > > > - Update VLAN input coloring table at runtime. > > > > - configures protocol priorities. > > > > - retrieve protocol and priority information > > > > Signed-off-by: Sunil Kumar Kori > > --- > > Sunil, > > Please send a V2 with the "Depends on: " properly set to indicate that Jerin's > patch needs to be apply first in order to avoid patch apply failure. > Sure, Will update. > Regards, > Cristian
Re: [PATCH v5 4/5] baseband/acc100: modify validation code for ACC101
On 5/24/22 02:08, Nicolas Chautru wrote:
The validation requirement is different for the two
devices.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 47
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 41475b2..e3706e0 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1289,6 +1289,21 @@
RTE_BBDEV_TURBO_HALF_ITERATION_EVEN);
}
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+
+static inline bool
+is_acc100(struct acc100_queue *q)
+{
+ return (q->d->device_variant == ACC100_VARIANT);
I keep insisting, but please rely on the PCI device ID, there is no need
to introduce a new field.
+}
+
+static inline bool
+validate_op_required(struct acc100_queue *q)
+{
+ return is_acc100(q);
+}
+#endif
+
/* Fill in a frame control word for LDPC decoding. */
static inline void
acc100_fcw_ld_fill(struct rte_bbdev_dec_op *op, struct acc100_fcw_ld *fcw,
@@ -2176,8 +2191,10 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validates turbo encoder parameters */
static inline int
-validate_enc_op(struct rte_bbdev_enc_op *op)
+validate_enc_op(struct rte_bbdev_enc_op *op, struct acc100_queue *q)
{
+ if (!validate_op_required(q))
+ return 0;
struct rte_bbdev_op_turbo_enc *turbo_enc = &op->turbo_enc;
struct rte_bbdev_op_enc_turbo_cb_params *cb = NULL;
struct rte_bbdev_op_enc_turbo_tb_params *tb = NULL;
@@ -2314,8 +2331,10 @@ static inline uint32_t hq_index(uint32_t offset)
}
/* Validates LDPC encoder parameters */
static inline int
-validate_ldpc_enc_op(struct rte_bbdev_enc_op *op)
+validate_ldpc_enc_op(struct rte_bbdev_enc_op *op, struct acc100_queue *q)
{
+ if (!validate_op_required(q))
+ return 0;
struct rte_bbdev_op_ldpc_enc *ldpc_enc = &op->ldpc_enc;
if (op->mempool == NULL) {
@@ -2367,8 +2386,10 @@ static inline uint32_t hq_index(uint32_t offset)
/* Validates LDPC decoder parameters */
static inline int
-validate_ldpc_dec_op(struct rte_bbdev_dec_op *op)
+validate_ldpc_dec_op(struct rte_bbdev_dec_op *op, struct acc100_queue *q)
{
+ if (!validate_op_required(q))
+ return 0;
struct rte_bbdev_op_ldpc_dec *ldpc_dec = &op->ldpc_dec;
if (op->mempool == NULL) {
@@ -2423,7 +2444,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_enc_op(op) == -1) {
+ if (validate_enc_op(op, q) == -1) {
rte_bbdev_log(ERR, "Turbo encoder validation failed");
return -EINVAL;
}
@@ -2477,7 +2498,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_ldpc_enc_op(ops[0]) == -1) {
+ if (validate_ldpc_enc_op(ops[0], q) == -1) {
rte_bbdev_log(ERR, "LDPC encoder validation failed");
return -EINVAL;
}
@@ -2539,7 +2560,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_ldpc_enc_op(op) == -1) {
+ if (validate_ldpc_enc_op(op, q) == -1) {
rte_bbdev_log(ERR, "LDPC encoder validation failed");
return -EINVAL;
}
@@ -2596,7 +2617,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_enc_op(op) == -1) {
+ if (validate_enc_op(op, q) == -1) {
rte_bbdev_log(ERR, "Turbo encoder validation failed");
return -EINVAL;
}
@@ -2669,8 +2690,10 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validates turbo decoder parameters */
static inline int
-validate_dec_op(struct rte_bbdev_dec_op *op)
+validate_dec_op(struct rte_bbdev_dec_op *op, struct acc100_queue *q)
{
+ if (!validate_op_required(q))
+ return 0;
struct rte_bbdev_op_turbo_dec *turbo_dec = &op->turbo_dec;
struct rte_bbdev_op_dec_turbo_cb_params *cb = NULL;
struct rte_bbdev_op_dec_turbo_tb_params *tb = NULL;
@@ -2816,7 +2839,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_dec_op(op) == -1) {
+ if (validate_dec_op(op, q) == -1) {
rte_bbdev_log(ERR, "Turbo decoder validation failed");
return -EINVAL;
}
@@ -3041,7 +3064,7 @@ static inline uint32_t hq_index(uint32_t offset)
#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Validate op structure */
- if (validate_ldpc_dec_op(op) == -1) {
+ if (validate_ldpc_dec
RE: [PATCH v2] app/procinfo: add devcie private info dump
> -Original Message-
> From: Min Hu (Connor)
> Subject: [PATCH v2] app/procinfo: add devcie private info dump
Typo: device*
> +static void
> +show_port_private_info(void)
> +{
> + int i;
> +
> + snprintf(bdr_str, MAX_STRING_LEN, " show - Port PMD Private ");
Better to have header message to be "Dump - Ports private information"
Looks ok to me.
Acked-by: Reshma Pattan
[PATCH v2 1/1] app/testpmd: support different input color method
From: Sunil Kumar Kori
To enable input coloring, based on VLAN or DSCP, patch adds
command line interface to configure the following:
- configuring input coloring using VLAN or DSCP while creating
meter i.e. during rte_mtr_create()
- Update VLAN input coloring table at runtime.
- configures protocol priorities.
- retrieve protocol and priority information
Depends-on: patch-22751 ("ethdev: mtr: support protocol based input color
selection")
Signed-off-by: Sunil Kumar Kori
---
v1..v2:
- Rebased to branch dpdk-next-net
- add CLIs for input coloring mechanism
app/test-pmd/cmdline.c | 4 +
app/test-pmd/cmdline_mtr.c | 558 -
app/test-pmd/cmdline_mtr.h | 4 +
3 files changed, 559 insertions(+), 7 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 1e5b294ab3..03647b2543 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -17972,6 +17972,10 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_del_port_meter_policy,
(cmdline_parse_inst_t *)&cmd_set_port_meter_profile,
(cmdline_parse_inst_t *)&cmd_set_port_meter_dscp_table,
+ (cmdline_parse_inst_t *)&cmd_set_port_meter_vlan_table,
+ (cmdline_parse_inst_t *)&cmd_set_port_meter_in_proto,
+ (cmdline_parse_inst_t *)&cmd_get_port_meter_in_proto,
+ (cmdline_parse_inst_t *)&cmd_get_port_meter_in_proto_prio,
(cmdline_parse_inst_t *)&cmd_set_port_meter_stats_mask,
(cmdline_parse_inst_t *)&cmd_show_port_meter_stats,
(cmdline_parse_inst_t *)&cmd_mcast_addr,
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index ad7ef6ad98..28ec92ad50 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -14,6 +14,7 @@
#include "cmdline_mtr.h"
#define PARSE_DELIMITER" \f\n\r\t\v"
+#define MAX_VLAN_TABLE_ENTRIES 16
#define MAX_DSCP_TABLE_ENTRIES 64
/** Display Meter Error Message */
@@ -82,6 +83,125 @@ parse_uint(uint64_t *value, const char *str)
return 0;
}
+static int
+parse_input_color_table_entries(char *str, enum rte_color **dscp_table,
+ enum rte_color **vlan_table)
+{
+ enum rte_color *vlan, *dscp;
+ char *token;
+ int i = 0;
+
+ token = strtok_r(str, PARSE_DELIMITER, &str);
+ if (token == NULL)
+ return 0;
+
+ /* Allocate memory for dscp table */
+ dscp = (enum rte_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
+ sizeof(enum rte_color));
+ if (dscp == NULL)
+ return -1;
+
+ while (1) {
+ if (strcmp(token, "G") == 0 || strcmp(token, "g") == 0)
+ dscp[i++] = RTE_COLOR_GREEN;
+ else if (strcmp(token, "Y") == 0 || strcmp(token, "y") == 0)
+ dscp[i++] = RTE_COLOR_YELLOW;
+ else if (strcmp(token, "R") == 0 || strcmp(token, "r") == 0)
+ dscp[i++] = RTE_COLOR_RED;
+ else {
+ free(dscp);
+ return -1;
+ }
+ if (i == MAX_DSCP_TABLE_ENTRIES)
+ break;
+
+ token = strtok_r(str, PARSE_DELIMITER, &str);
+ if (token == NULL) {
+ free(dscp);
+ return -1;
+ }
+ }
+
+ *dscp_table = dscp;
+
+ token = strtok_r(str, PARSE_DELIMITER, &str);
+ if (token == NULL)
+ return 0;
+
+ /* Allocate memory for vlan table */
+ vlan = (enum rte_color *)malloc(MAX_VLAN_TABLE_ENTRIES *
+ sizeof(enum rte_color));
+ if (vlan == NULL)
+ return -1;
+
+ i = 0;
+ while (1) {
+ if (strcmp(token, "G") == 0 || strcmp(token, "g") == 0)
+ vlan[i++] = RTE_COLOR_GREEN;
+ else if (strcmp(token, "Y") == 0 || strcmp(token, "y") == 0)
+ vlan[i++] = RTE_COLOR_YELLOW;
+ else if (strcmp(token, "R") == 0 || strcmp(token, "r") == 0)
+ vlan[i++] = RTE_COLOR_RED;
+ else {
+ free(vlan);
+ return -1;
+ }
+ if (i == MAX_VLAN_TABLE_ENTRIES)
+ break;
+
+ token = strtok_r(str, PARSE_DELIMITER, &str);
+ if (token == NULL) {
+ free(vlan);
+ return -1;
+ }
+ }
+
+ *vlan_table = vlan;
+ return 0;
+}
+
+static int
+parse_vlan_table_entries(char *str, enum rte_color **vlan_table)
+{
+ char *token;
+ int i = 0;
+
+ token = strtok_r(str, PARSE_DELIMITER, &str);
+ if (token == NULL)
+ return 0;
+
+ /* Allocate memory for vlan table */
+ *vlan_table = (enum rte_color *)malloc(MAX_VLAN_TABLE_ENTRIES *
+ si
RE: [PATCH v2 1/1] app/testpmd: support different input color method
> -Original Message-
> From: sk...@marvell.com
> Sent: Wednesday, May 25, 2022 3:37 PM
> To: Li, Xiaoyun ; Singh, Aman Deep
> ; Zhang, Yuying ;
> Dumitrescu, Cristian
> Cc: dev@dpdk.org; Sunil Kumar Kori
> Subject: [PATCH v2 1/1] app/testpmd: support different input color method
>
> From: Sunil Kumar Kori
>
> To enable input coloring, based on VLAN or DSCP, patch adds
> command line interface to configure the following:
>
> - configuring input coloring using VLAN or DSCP while creating
>meter i.e. during rte_mtr_create()
>
> - Update VLAN input coloring table at runtime.
>
> - configures protocol priorities.
>
> - retrieve protocol and priority information
>
> Depends-on: patch-22751 ("ethdev: mtr: support protocol based input color
> selection")
>
> Signed-off-by: Sunil Kumar Kori
> ---
> v1..v2:
> - Rebased to branch dpdk-next-net
> - add CLIs for input coloring mechanism
>
> app/test-pmd/cmdline.c | 4 +
> app/test-pmd/cmdline_mtr.c | 558
> -
Acked-by: Cristian Dumitrescu
Re: [RFT v2 1/3] random: add rte_rand_float()
On 2022-05-25 00:18, Stephen Hemminger wrote:
> The PIE code and other applications can benefit from having a
> fast way to get a random floating point value. This new function
> is equivalent to erand48_r in the standard library.
>
Seems like a good addition to the API.
> Signed-off-by: Stephen Hemminger
> ---
> app/test/test_rand_perf.c | 7 +++
> doc/guides/rel_notes/release_22_07.rst | 5 +
> lib/eal/common/rte_random.c| 21 +
> lib/eal/include/rte_random.h | 17 +
> lib/eal/version.map| 1 +
> 5 files changed, 51 insertions(+)
>
> diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
> index fe797ebfa1ca..f3602da5b2d4 100644
> --- a/app/test/test_rand_perf.c
> +++ b/app/test/test_rand_perf.c
> @@ -20,6 +20,7 @@ static volatile uint64_t vsum;
>
> enum rand_type {
> rand_type_64,
> + rand_type_float,
> rand_type_bounded_best_case,
> rand_type_bounded_worst_case
> };
> @@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
> switch (rand_type) {
> case rand_type_64:
> return "Full 64-bit [rte_rand()]";
> + case rand_type_float:
> + return "Floating point [rte_rand_float()]";
> case rand_type_bounded_best_case:
> return "Bounded average best-case [rte_rand_max()]";
> case rand_type_bounded_worst_case:
> @@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
> case rand_type_64:
> sum += rte_rand();
> break;
> + case rand_type_float:
> + sum += rte_rand_float() * UINT64_MAX;
> + break;
> case rand_type_bounded_best_case:
> sum += rte_rand_max(BEST_CASE_BOUND);
> break;
> @@ -83,6 +89,7 @@ test_rand_perf(void)
> printf("Pseudo-random number generation latencies:\n");
>
> test_rand_perf_type(rand_type_64);
> + test_rand_perf_type(rand_type_float);
> test_rand_perf_type(rand_type_bounded_best_case);
> test_rand_perf_type(rand_type_bounded_worst_case);
>
> diff --git a/doc/guides/rel_notes/release_22_07.rst
> b/doc/guides/rel_notes/release_22_07.rst
> index e49cacecefd4..128d4fca85b3 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -104,6 +104,11 @@ New Features
> * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
> * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
>
> +* ** Added function get random floating point number.**
> +
> + Added the function ``rte_rand_float()`` to provide a pseudo-random
> + floating point number.
> +
>
> Removed Items
> -
> diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> index 4535cc980cec..024c3c41dc16 100644
> --- a/lib/eal/common/rte_random.c
> +++ b/lib/eal/common/rte_random.c
> @@ -6,6 +6,7 @@
> #include
> #endif
> #include
> +#include
>
Is this API available in FreeBSD? In Windows?
> #include
> #include
> @@ -173,6 +174,26 @@ rte_rand_max(uint64_t upper_bound)
> return res;
> }
>
> +double
> +rte_rand_float(void)
> +{
> + struct rte_rand_state *state = __rte_rand_get_state();
> + union ieee754_double u = {
> + .ieee = {
> + .negative = 0,
> + .exponent = IEEE754_DOUBLE_BIAS,
> + },
> + };
> + uint64_t val;
> +
> + /* Take 64 bit random value and put it into the mantissa */
> + val = __rte_rand_lfsr258(state);
> + u.ieee.mantissa0 = val >> 32; /* only 20 bits used */
> + u.ieee.mantissa1 = (uint32_t)val;
Why do you have a cast here, and not for mantissa0? Both will incur a
64->32 conversion, assuming unsigned int is 32-bit (which it is on all
platforms DPDK supports?).
The naive implementation (i.e., (double)rte_rand() / (double)UINT64_MAX)
would cost a floating point multiplication. That's why you access the
underlying IEEE754 bits directly. Correct?
> +
> + return u.d - 1.0;
> +}
> +
> static uint64_t
> __rte_random_initial_seed(void)
> {
> diff --git a/lib/eal/include/rte_random.h b/lib/eal/include/rte_random.h
> index 29f5f1325a30..553beb2d9c6f 100644
> --- a/lib/eal/include/rte_random.h
> +++ b/lib/eal/include/rte_random.h
> @@ -65,6 +65,23 @@ rte_rand(void);
> uint64_t
> rte_rand_max(uint64_t upper_bound);
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Generates a pseudo-random floating point number.
> + *
> + * This function returns a nonnegative double-precison floating random
> + * number uniformly distributed over the interval [0.0, 1.0).
> + *
> + * If called from lcore threads, this function is thread-safe.
> + *
> + * @return
> + * A pseudo-random value between 0 and 1.0.
> + */
> +__rte_experimental
> +double rte_rand_float(void);
> +
Newline af
RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 devices
> -Original Message- > From: Zhang, Qi Z > Sent: Monday, May 23, 2022 7:22 PM > To: Jeff Daly ; Thomas Monjalon > ; dev@dpdk.org > Cc: Stephen Douthit ; Yang, Qiming > ; Wu, Wenjun1 > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 > devices > > Caution: This is an external email. Please take care when clicking links or > opening attachments. > > > > -Original Message- > > From: Jeff Daly > > Sent: Monday, May 23, 2022 10:14 PM > > To: Zhang, Qi Z ; Thomas Monjalon > > ; dev@dpdk.org > > Cc: Stephen Douthit ; Yang, Qiming > > ; Wu, Wenjun1 > > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 > > devices > > > > > > > > > -Original Message- > > > From: Zhang, Qi Z > > > Sent: Monday, May 23, 2022 1:37 AM > > > To: Jeff Daly ; Thomas Monjalon > > > ; dev@dpdk.org > > > Cc: Stephen Douthit ; Yang, Qiming > > > ; Wu, Wenjun1 > > > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the > > > X550 devices > > > > > > Caution: This is an external email. Please take care when clicking > > > links or opening attachments. > > > > > > > > > > -Original Message- > > > > From: Jeff Daly > > > > Sent: Saturday, May 21, 2022 2:03 AM > > > > To: Zhang, Qi Z ; Thomas Monjalon > > > > ; dev@dpdk.org > > > > Cc: Stephen Douthit ; Yang, Qiming > > > > ; Wu, Wenjun1 > > > > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the > > > > X550 devices > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Zhang, Qi Z > > > > > Sent: Thursday, May 19, 2022 8:15 PM > > > > > To: Thomas Monjalon ; dev@dpdk.org > > > > > Cc: Stephen Douthit ; Jeff Daly > > > > > ; Yang, Qiming ; > > > > > Wu, > > > > > Wenjun1 > > > > > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the > > > > > X550 devices > > > > > > > > > > Caution: This is an external email. Please take care when > > > > > clicking links or opening attachments. > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Thomas Monjalon > > > > > > Sent: Wednesday, April 13, 2022 10:21 PM > > > > > > To: dev@dpdk.org > > > > > > Cc: Stephen Douthit ; Jeff Daly > > > > > > ; Wang, Haiyue > > > > > > ; Yang, Qiming ; > > > > > > Wu, Wenjun1 > > > > > > Subject: Re: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on > > > > > > the > > > > > > X550 devices > > > > > > > > > > > > Please, could we have a review of this patch? > > > > > > +Cc new ixgbe maintainers > > > > > > > > > > > > > > > > > > 07/03/2022 23:34, je...@silicom-usa.com: > > > > > > > From: Stephen Douthit > > > > > > > > > > > > > > 1G Cu SFPs are not officially supported on the X552/X553 > > > > > > > family of devices but treat them as 1G SX modules since they > > > > > > > usually > > work. > > > > > > > Print a warning though since support isn't validated, > > > > > > > similar to what already happens for other unofficially > > > > > > > supported SFPs enabled via the allow_unsupported_sfps > > > > > > > parameter inherited from the mainline > > > > > Linux driver. > > > > > > > > > > > > > > Signed-off-by: Stephen Douthit > > > > > > > Signed-off-by: Jeff Daly > > > > > > > > > > I think we need a devargs for this feature with well > > > > > documentation So, it should not break existing behavior by > > > > > default, but allow people to take risk if they know what they are > doing. > > > > > > > > > > > > > there was already a patch submitted to IWL mailing list for this > > > > feature in the base driver, which was rejected. > > > > https://patchwork.ozlabs.org/project/intel-wired- > > > > lan/patch/20220414201329.27714-1-je...@silicom-usa.com/ > > > > > > OK, thanks for sharing this, > > > > > > But base on the concern of the previous comment > > > > > > " As for 1G Cu SFP treating it as 1G SX, some 1G-Base-T SFP modules > > > require the use of RX_ILOS and some Intel Ethernet products don't > > > support > > that." > > > > > > We may have a risk to accept the code as default behavior > > > > > > But devargs is allowed in DPDK for device-specific features. > > > > > > > ok, I will submit a revised patch that uses a devargs (or whatever) > > switch to allow the behavior when selected explicitly. > > > > But, can we *please* STOP marking patches as superseded when a > > follow-up patch > > hasn't been submitted yet!?I've marked the patch as 'Changes > Requested' for > > now. > > Sure, I should follow, thanks to correct his, but a little bit surprise, why > this > looks like a big deal, it just a shortcut when I expected a new version will > come then I skip one status change, I think mailing list already have > everything about the patch status for you. > Maybe I'm not understanding the terms being used then in the mailing list status. If you expect a new version (that doesn't exist yet) then wouldn't this be more aptly "Changes Requested" vs. "Superseded". Superseded implies there's a new version that exists and this current one no l
RE: [RFT v2 1/3] random: add rte_rand_float()
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Wednesday, 25 May 2022 16.46 > > On 2022-05-25 00:18, Stephen Hemminger wrote: > > The PIE code and other applications can benefit from having a > > fast way to get a random floating point value. This new function > > is equivalent to erand48_r in the standard library. > > > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this API may change without prior notice > > + * > > + * Generates a pseudo-random floating point number. > > + * > > + * This function returns a nonnegative double-precison floating > random > > + * number uniformly distributed over the interval [0.0, 1.0). > > + * > > + * If called from lcore threads, this function is thread-safe. > > + * > > + * @return > > + * A pseudo-random value between 0 and 1.0. > > + */ > > +__rte_experimental > > +double rte_rand_float(void); > > + > > Newline after "double" missing. > > I would call it something else than "float", in particular since it > doesn't return "float" but a "double" type floating point value. > > rte_drand() maybe? Short, but might be confused with rte_rand(), given > the visual similarity. I still I would still prefer that over > rte_rand_double(). Although we use foo32() and foo64() for many functions returning uint32_t/uint64_t, I don't think we need a common (and preferably short) postfix for functions returning double. Such functions should be rare. So: +1 to rte_drand() - it resembles drand48() in stdlib.h.
Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
25/05/2022 13:48, Ray Kinsella: > > Thomas Monjalon writes: > > > The AltiVec header file is defining "vector", except in C++ build. > > The keyword "vector" may conflict easily. > > As a rule, it is better to use the alternative keyword "__vector". > > > > The DPDK header file rte_altivec.h takes care of undefining "vector", > > so the applications and dependencies are free to define the name "vector". > > > > This is a compatibility breakage for applications which were using > > the keyword "vector" for its AltiVec meaning. > > > > Signed-off-by: Thomas Monjalon > > --- > > doc/guides/rel_notes/release_22_07.rst | 5 + > > lib/eal/ppc/include/rte_altivec.h | 7 +++ > > 2 files changed, 12 insertions(+) > > > > Acked-by: Ray Kinsella Just to make sure, we are all OK to break compatibility of rte_altivec.h? It means the keyword vector is not available anymore with this #include. Please confirm it is OK to merge in DPDK 22.07.
Re: [RFT v2 1/3] random: add rte_rand_float()
On Wed, 25 May 2022 14:45:37 +
Mattias Rönnblom wrote:
> On 2022-05-25 00:18, Stephen Hemminger wrote:
> > The PIE code and other applications can benefit from having a
> > fast way to get a random floating point value. This new function
> > is equivalent to erand48_r in the standard library.
> >
>
> Seems like a good addition to the API.
>
> > Signed-off-by: Stephen Hemminger
> > ---
> > app/test/test_rand_perf.c | 7 +++
> > doc/guides/rel_notes/release_22_07.rst | 5 +
> > lib/eal/common/rte_random.c| 21 +
> > lib/eal/include/rte_random.h | 17 +
> > lib/eal/version.map| 1 +
> > 5 files changed, 51 insertions(+)
> >
> > diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
> > index fe797ebfa1ca..f3602da5b2d4 100644
> > --- a/app/test/test_rand_perf.c
> > +++ b/app/test/test_rand_perf.c
> > @@ -20,6 +20,7 @@ static volatile uint64_t vsum;
> >
> > enum rand_type {
> > rand_type_64,
> > + rand_type_float,
> > rand_type_bounded_best_case,
> > rand_type_bounded_worst_case
> > };
> > @@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
> > switch (rand_type) {
> > case rand_type_64:
> > return "Full 64-bit [rte_rand()]";
> > + case rand_type_float:
> > + return "Floating point [rte_rand_float()]";
> > case rand_type_bounded_best_case:
> > return "Bounded average best-case [rte_rand_max()]";
> > case rand_type_bounded_worst_case:
> > @@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
> > case rand_type_64:
> > sum += rte_rand();
> > break;
> > + case rand_type_float:
> > + sum += rte_rand_float() * UINT64_MAX;
> > + break;
> > case rand_type_bounded_best_case:
> > sum += rte_rand_max(BEST_CASE_BOUND);
> > break;
> > @@ -83,6 +89,7 @@ test_rand_perf(void)
> > printf("Pseudo-random number generation latencies:\n");
> >
> > test_rand_perf_type(rand_type_64);
> > + test_rand_perf_type(rand_type_float);
> > test_rand_perf_type(rand_type_bounded_best_case);
> > test_rand_perf_type(rand_type_bounded_worst_case);
> >
> > diff --git a/doc/guides/rel_notes/release_22_07.rst
> > b/doc/guides/rel_notes/release_22_07.rst
> > index e49cacecefd4..128d4fca85b3 100644
> > --- a/doc/guides/rel_notes/release_22_07.rst
> > +++ b/doc/guides/rel_notes/release_22_07.rst
> > @@ -104,6 +104,11 @@ New Features
> > * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
> > * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
> >
> > +* ** Added function get random floating point number.**
> > +
> > + Added the function ``rte_rand_float()`` to provide a pseudo-random
> > + floating point number.
> > +
> >
> > Removed Items
> > -
> > diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> > index 4535cc980cec..024c3c41dc16 100644
> > --- a/lib/eal/common/rte_random.c
> > +++ b/lib/eal/common/rte_random.c
> > @@ -6,6 +6,7 @@
> > #include
> > #endif
> > #include
> > +#include
> >
>
> Is this API available in FreeBSD? In Windows?
>
> > #include
> > #include
> > @@ -173,6 +174,26 @@ rte_rand_max(uint64_t upper_bound)
> > return res;
> > }
> >
> > +double
> > +rte_rand_float(void)
> > +{
> > + struct rte_rand_state *state = __rte_rand_get_state();
> > + union ieee754_double u = {
> > + .ieee = {
> > + .negative = 0,
> > + .exponent = IEEE754_DOUBLE_BIAS,
> > + },
> > + };
> > + uint64_t val;
> > +
> > + /* Take 64 bit random value and put it into the mantissa */
> > + val = __rte_rand_lfsr258(state);
> > + u.ieee.mantissa0 = val >> 32; /* only 20 bits used */
> > + u.ieee.mantissa1 = (uint32_t)val;
>
> Why do you have a cast here, and not for mantissa0? Both will incur a
> 64->32 conversion, assuming unsigned int is 32-bit (which it is on all
> platforms DPDK supports?).
Yes, cast there is unnecessary. A little concerned that some compiler
might complain about loss of precision.
>
> The naive implementation (i.e., (double)rte_rand() / (double)UINT64_MAX)
> would cost a floating point multiplication. That's why you access the
> underlying IEEE754 bits directly. Correct?
Yes, avoiding floating point math, and directly setting bits keeps full
precision.
[v5, 00/11] Add JSON vector set support to fips validation
Adds a very basic introduction to JSON vector sets in the fips validation example application. This patch set will only introduce the AES-GCM test using a JSON request file because the other algorithms need more information than what is given in the new JSON format. v5: * AES_CBC support appended in series. Brandon Lo (8): examples/fips_validation: add jansson dependency examples/fips_validation: add json info to header examples/fips_validation: add json parsing examples/fips_validation: allow json file as input examples/fips_validation: add json to gcm test examples/fips_validation: add json to hmac examples/fips_validation: implement json cmac test examples/fips_validation: add parsing for cmac Gowrishankar Muthukrishnan (3): examples/fips_validation: cleanup bypass tests in response file examples/fips_validation: reset IV generation in every test group examples/fips_validation: add parsing for aes_cbc examples/fips_validation/fips_validation.c| 117 ++- examples/fips_validation/fips_validation.h| 64 +++- .../fips_validation/fips_validation_aes.c | 223 .../fips_validation/fips_validation_cmac.c| 80 + .../fips_validation/fips_validation_gcm.c | 152 - .../fips_validation/fips_validation_hmac.c| 93 + examples/fips_validation/main.c | 323 +++--- examples/fips_validation/meson.build | 4 + 8 files changed, 995 insertions(+), 61 deletions(-) -- 2.25.1
[v5, 01/11] examples/fips_validation: add jansson dependency
From: Brandon Lo
Added a check for RTE_HAS_JANSSON into the meson
configuration file for JSON support.
Signed-off-by: Brandon Lo
---
examples/fips_validation/meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/examples/fips_validation/meson.build
b/examples/fips_validation/meson.build
index 7eef456318..8cd63066b5 100644
--- a/examples/fips_validation/meson.build
+++ b/examples/fips_validation/meson.build
@@ -21,3 +21,7 @@ sources = files(
'fips_dev_self_test.c',
'main.c',
)
+
+if dpdk_conf.has('RTE_HAS_JANSSON')
+ext_deps += jansson_dep
+endif
--
2.25.1
[v5, 02/11] examples/fips_validation: add json info to header
From: Brandon Lo
Added json-specific functions and other information needed to
test the new FIPS test vectors.
Signed-off-by: Brandon Lo
Signed-off-by: Gowrishankar Muthukrishnan
---
v5:
* fix typo in macro name for prefixes.
v2:
* fix type of prefix to suffix
---
examples/fips_validation/fips_validation.c | 6 +--
examples/fips_validation/fips_validation.h | 48 --
2 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 94253eaee8..38c99b291c 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -270,11 +270,11 @@ parse_file_type(const char *path)
{
const char *tmp = path + strlen(path) - 3;
- if (strstr(tmp, REQ_FILE_PERFIX))
+ if (strstr(tmp, REQ_FILE_PREFIX))
info.file_type = FIPS_TYPE_REQ;
- else if (strstr(tmp, RSP_FILE_PERFIX))
+ else if (strstr(tmp, RSP_FILE_PREFIX))
info.file_type = FIPS_TYPE_RSP;
- else if (strstr(path, FAX_FILE_PERFIX))
+ else if (strstr(path, FAX_FILE_PREFIX))
info.file_type = FIPS_TYPE_FAX;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index aaadf01ba8..a1c83a9a6a 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -5,6 +5,10 @@
#ifndef _FIPS_VALIDATION_H_
#define _FIPS_VALIDATION_H_
+#ifdef RTE_HAS_JANSSON
+#include
+#endif /* RTE_HAS_JANSSON */
+
#define FIPS_PARSE_ERR(fmt, args) \
RTE_LOG(ERR, USER1, "FIPS parse error" ## fmt ## "\n", ## args)
@@ -21,9 +25,12 @@
#define POSITIVE_TEST 0
#define NEGATIVE_TEST -1
-#define REQ_FILE_PERFIX"req"
-#define RSP_FILE_PERFIX"rsp"
-#define FAX_FILE_PERFIX"fax"
+#define REQ_FILE_PREFIX"req"
+#define RSP_FILE_PREFIX"rsp"
+#define FAX_FILE_PREFIX"fax"
+#define JSON_FILE_PREFIX "json"
+
+#define ACVVERSION "1.0"
enum fips_test_algorithms {
FIPS_TEST_ALGO_AES = 0,
@@ -40,7 +47,8 @@ enum fips_test_algorithms {
enum file_types {
FIPS_TYPE_REQ = 1,
FIPS_TYPE_FAX,
- FIPS_TYPE_RSP
+ FIPS_TYPE_RSP,
+ FIPS_TYPE_JSON,
};
enum fips_test_op {
@@ -161,6 +169,23 @@ struct gcm_interim_data {
uint8_t gen_iv;
};
+#ifdef RTE_HAS_JANSSON
+struct fips_test_json_info {
+ /* Information used for reading from json */
+ json_t *json_root;
+ json_t *json_vector_set;
+ json_t *json_test_group;
+ json_t *json_test_case;
+ /* Location of json write output */
+ json_t *json_write_root;
+ json_t *json_write_group;
+ json_t *json_write_set;
+ json_t *json_write_case;
+ /* Other info */
+ uint8_t is_sample;
+};
+#endif /* RTE_HAS_JANSSON */
+
struct fips_test_interim_info {
FILE *fp_rd;
FILE *fp_wr;
@@ -196,6 +221,10 @@ struct fips_test_interim_info {
extern struct fips_test_vector vec;
extern struct fips_test_interim_info info;
+#ifdef RTE_HAS_JANSSON
+extern struct fips_test_json_info json_info;
+#endif /* RTE_HAS_JANSSON */
+
int
fips_test_init(const char *req_file_path, const char *rsp_file_path,
const char *device_name);
@@ -212,6 +241,17 @@ fips_test_parse_one_case(void);
void
fips_test_write_one_case(void);
+#ifdef RTE_HAS_JANSSON
+int
+fips_test_parse_one_json_vector_set(void);
+
+int
+fips_test_parse_one_json_group(void);
+
+int
+fips_test_parse_one_json_case(void);
+#endif /* RTE_HAS_JANSSON */
+
int
parse_test_aes_init(void);
--
2.25.1
[v5, 03/11] examples/fips_validation: add json parsing
From: Brandon Lo
Added functions to parse the required information from a vector set
given in the new json format.
Signed-off-by: Brandon Lo
---
v3:
* fix checkpatch warnings
v2:
* fix for loop initialization
---
examples/fips_validation/fips_validation.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 38c99b291c..6594a15579 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -276,6 +276,8 @@ parse_file_type(const char *path)
info.file_type = FIPS_TYPE_RSP;
else if (strstr(path, FAX_FILE_PREFIX))
info.file_type = FIPS_TYPE_FAX;
+ else if (strstr(path, JSON_FILE_PREFIX))
+ info.file_type = FIPS_TYPE_JSON;
else
return -EINVAL;
@@ -311,6 +313,21 @@ fips_test_init(const char *req_file_path, const char
*rsp_file_path,
return -EINVAL;
}
+ if (info.file_type == FIPS_TYPE_JSON) {
+#ifdef RTE_HAS_JANSSON
+ json_error_t error;
+ json_info.json_root = json_loadf(info.fp_rd, 0, &error);
+ if (!json_info.json_root) {
+ RTE_LOG(ERR, USER1, "Cannot parse json file %s (line
%d, column %d)\n",
+ req_file_path, error.line, error.column);
+ return -EINVAL;
+ }
+#else /* RTE_HAS_JANSSON */
+ RTE_LOG(ERR, USER1, "No json library configured.\n");
+ return -EINVAL;
+#endif /* RTE_HAS_JANSSON */
+ }
+
info.fp_wr = fopen(rsp_file_path, "w");
if (!info.fp_wr) {
RTE_LOG(ERR, USER1, "Cannot open file %s\n", rsp_file_path);
@@ -329,6 +346,9 @@ fips_test_init(const char *req_file_path, const char
*rsp_file_path,
return -EINVAL;
}
+ if (info.file_type == FIPS_TYPE_JSON)
+ return 0;
+
if (fips_test_parse_header() < 0) {
RTE_LOG(ERR, USER1, "Failed parsing header\n");
return -1;
@@ -428,6 +448,78 @@ fips_test_write_one_case(void)
fprintf(info.fp_wr, "%s\n", info.vec[i]);
}
+#ifdef RTE_HAS_JANSSON
+int
+fips_test_parse_one_json_vector_set(void)
+{
+ json_t *algo_obj = json_object_get(json_info.json_vector_set,
"algorithm");
+ const char *algo_str = json_string_value(algo_obj);
+
+ /* Vector sets contain the algorithm type, and nothing else we need. */
+ if (strstr(algo_str, "AES-GCM"))
+ info.algo = FIPS_TEST_ALGO_AES_GCM;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+int
+fips_test_parse_one_json_group(void)
+{
+ int ret, i;
+ json_int_t val;
+ json_t *param;
+
+ if (info.interim_callbacks) {
+ char json_value[256];
+ for (i = 0; info.interim_callbacks[i].key != NULL; i++) {
+ param = json_object_get(json_info.json_test_group,
+ info.interim_callbacks[i].key);
+ val = json_integer_value(param);
+ snprintf(json_value, 255, "%"JSON_INTEGER_FORMAT, val);
+ /* First argument is blank because the key
+* is not included in the string being parsed.
+*/
+ ret = info.interim_callbacks[i].cb(
+ "", json_value,
+ info.interim_callbacks[i].val
+ );
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+int
+fips_test_parse_one_json_case(void)
+{
+ uint32_t i;
+ int ret = 0;
+ json_t *param;
+
+ for (i = 0; info.callbacks[i].key != NULL; i++) {
+ param = json_object_get(json_info.json_test_case,
info.callbacks[i].key);
+ if (param) {
+ strcpy(info.one_line_text, json_string_value(param));
+ /* First argument is blank because the key
+* is not included in the string being parsed.
+*/
+ ret = info.callbacks[i].cb(
+ "", info.one_line_text,
+ info.callbacks[i].val
+ );
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+#endif /* RTE_HAS_JANSSON */
+
static int
parser_read_uint64_hex(uint64_t *value, const char *p)
{
--
2.25.1
[v5, 04/11] examples/fips_validation: allow json file as input
From: Brandon Lo
Added the ability to use the json format as the input
and output of the example application.
Signed-off-by: Brandon Lo
Signed-off-by: Gowrishankar Muthukrishnan
--
v5:
* fix to check info.file_type in json file type as well.
v3:
* fix checkpatch warnings
v2:
* remove use_json variable
---
examples/fips_validation/main.c | 197 +++-
1 file changed, 194 insertions(+), 3 deletions(-)
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e06ae37567..3d841e5bfd 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -34,11 +34,17 @@ enum {
OPT_CRYPTODEV_BK_ID_NUM,
#define OPT_CRYPTODEV_BK_DIR_KEY"broken-test-dir"
OPT_CRYPTODEV_BK_DIR_KEY_NUM,
+#define OPT_USE_JSON"use-json"
+ OPT_USE_JSON_NUM,
};
struct fips_test_vector vec;
struct fips_test_interim_info info;
+#ifdef RTE_HAS_JANSSON
+struct fips_test_json_info json_info;
+#endif /* RTE_HAS_JANSSON */
+
struct cryptodev_fips_validate_env {
const char *req_path;
const char *rsp_path;
@@ -166,6 +172,11 @@ cryptodev_fips_validate_app_uninit(void)
static int
fips_test_one_file(void);
+#ifdef RTE_HAS_JANSSON
+static int
+fips_test_one_json_file(void);
+#endif /* RTE_HAS_JANSSON */
+
static int
parse_cryptodev_arg(char *arg)
{
@@ -425,8 +436,17 @@ main(int argc, char *argv[])
goto exit;
}
-
+#ifdef RTE_HAS_JANSSON
+ if (info.file_type == FIPS_TYPE_JSON) {
+ ret = fips_test_one_json_file();
+ json_decref(json_info.json_root);
+ } else {
+ ret = fips_test_one_file();
+ }
+#else /* RTE_HAS_JANSSON */
ret = fips_test_one_file();
+#endif /* RTE_HAS_JANSSON */
+
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Failed test %s\n",
ret, env.req_path);
@@ -481,7 +501,17 @@ main(int argc, char *argv[])
break;
}
+#ifdef RTE_HAS_JANSSON
+ if (info.file_type == FIPS_TYPE_JSON) {
+ ret = fips_test_one_json_file();
+ json_decref(json_info.json_root);
+ } else {
+ ret = fips_test_one_file();
+ }
+#else /* RTE_HAS_JANSSON */
ret = fips_test_one_file();
+#endif /* RTE_HAS_JANSSON */
+
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Failed test
%s\n",
ret, req_path);
@@ -1219,7 +1249,8 @@ fips_generic_test(void)
struct fips_val val = {NULL, 0};
int ret;
- fips_test_write_one_case();
+ if (info.file_type != FIPS_TYPE_JSON)
+ fips_test_write_one_case();
ret = fips_run_test();
if (ret < 0) {
@@ -1238,6 +1269,7 @@ fips_generic_test(void)
switch (info.file_type) {
case FIPS_TYPE_REQ:
case FIPS_TYPE_RSP:
+ case FIPS_TYPE_JSON:
if (info.parse_writeback == NULL)
return -EPERM;
ret = info.parse_writeback(&val);
@@ -1253,7 +1285,8 @@ fips_generic_test(void)
break;
}
- fprintf(info.fp_wr, "\n");
+ if (info.file_type != FIPS_TYPE_JSON)
+ fprintf(info.fp_wr, "\n");
free(val.val);
return 0;
@@ -1844,3 +1877,161 @@ fips_test_one_file(void)
return ret;
}
+
+#ifdef RTE_HAS_JANSSON
+static int
+fips_test_json_init_writeback(void)
+{
+ json_t *session_info, *session_write;
+ session_info = json_array_get(json_info.json_root, 0);
+ session_write = json_object();
+ json_info.json_write_root = json_array();
+
+ json_object_set(session_write, "jwt",
+ json_object_get(session_info, "jwt"));
+ json_object_set(session_write, "url",
+ json_object_get(session_info, "url"));
+ json_object_set(session_write, "isSample",
+ json_object_get(session_info, "isSample"));
+
+ json_info.is_sample = json_boolean_value(
+ json_object_get(session_info, "isSample"));
+
+ json_array_append_new(json_info.json_write_root, session_write);
+ return 0;
+}
+
+static int
+fips_test_one_test_case(void)
+{
+ int ret;
+
+ ret = fips_test_parse_one_json_case();
+
+ switch (ret) {
+ case 0:
+ ret = test_ops.test();
+ if (ret == 0)
+ break;
+ RTE_LOG(ERR, USER1, "Error %i: test block\n",
+ ret);
+ break;
+ case 1:
+ break;
+ default:
+ RTE_LOG(ERR, USER1, "Error %i: Parse blo
[v5, 05/11] examples/fips_validation: add json to gcm test
From: Brandon Lo
Adds json-specific testing and writeback function. Allows
the user to test AES-GCM vector sets.
Signed-off-by: Brandon Lo
---
v3:
* fix checkpatch warnings
---
examples/fips_validation/fips_validation.h| 3 +
.../fips_validation/fips_validation_gcm.c | 151 +-
examples/fips_validation/main.c | 3 +-
3 files changed, 155 insertions(+), 2 deletions(-)
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index a1c83a9a6a..8b9d528c53 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -250,6 +250,9 @@ fips_test_parse_one_json_group(void);
int
fips_test_parse_one_json_case(void);
+
+int
+parse_test_gcm_json_init(void);
#endif /* RTE_HAS_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_gcm.c
b/examples/fips_validation/fips_validation_gcm.c
index 250d09bf90..3604b21f13 100644
--- a/examples/fips_validation/fips_validation_gcm.c
+++ b/examples/fips_validation/fips_validation_gcm.c
@@ -6,6 +6,10 @@
#include
#include
+#ifdef RTE_HAS_JANSSON
+#include
+#endif /* RTE_HAS_JANSSON */
+
#include
#include
@@ -37,6 +41,27 @@
#define OP_ENC_EXT_STR "ExtIV"
#define OP_ENC_INT_STR "IntIV"
+#define KEYLEN_JSON_STR"keyLen"
+#define IVLEN_JSON_STR "ivLen"
+#define PAYLOADLEN_JSON_STR"payloadLen"
+#define AADLEN_JSON_STR"aadLen"
+#define TAGLEN_JSON_STR"tagLen"
+
+#define KEY_JSON_STR "key"
+#define IV_JSON_STR"iv"
+#define PT_JSON_STR"pt"
+#define CT_JSON_STR"ct"
+#define AAD_JSON_STR "aad"
+#define TAG_JSON_STR "tag"
+#define DIR_JSON_STR "direction"
+
+#define OP_ENC_JSON_STR"encrypt"
+#define OP_DEC_JSON_STR"decrypt"
+
+#define IVGEN_JSON_STR "ivGen"
+#define OP_ENC_EXT_JSON_STR"external"
+#define OP_ENC_INT_JSON_STR"internal"
+
#define NEG_TEST_STR "FAIL"
/**
@@ -136,6 +161,40 @@ struct fips_test_callback gcm_enc_vectors[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef RTE_HAS_JANSSON
+struct fips_test_callback gcm_dec_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str, &vec.aead.key},
+ {IV_JSON_STR, parse_uint8_known_len_hex_str, &vec.iv},
+ {CT_JSON_STR, parse_gcm_pt_ct_str, &vec.ct},
+ {AAD_JSON_STR, parse_gcm_aad_str, &vec.aead.aad},
+ {TAG_JSON_STR, parse_uint8_known_len_hex_str,
+ &vec.aead.digest},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback gcm_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_read_uint32_bit_val, &vec.aead.key},
+ {IVLEN_JSON_STR, parser_read_uint32_bit_val, &vec.iv},
+ {PAYLOADLEN_JSON_STR, parser_read_gcm_pt_len, &vec.pt},
+ {PAYLOADLEN_JSON_STR, parser_read_uint32_bit_val, &vec.ct},
+ /**< The NIST json test vectors use 'payloadLen' to denote
input text
+* length in case of decrypt & encrypt operations.
+*/
+ {AADLEN_JSON_STR, parser_read_uint32_bit_val, &vec.aead.aad},
+ {TAGLEN_JSON_STR, parser_read_uint32_bit_val,
+ &vec.aead.digest},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback gcm_enc_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str, &vec.aead.key},
+ {IV_JSON_STR, parse_uint8_known_len_hex_str, &vec.iv},
+ {PT_JSON_STR, parse_gcm_pt_ct_str, &vec.pt},
+ {AAD_JSON_STR, parse_gcm_aad_str, &vec.aead.aad},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+#endif /* RTE_HAS_JANSSON */
+
static int
parse_test_gcm_writeback(struct fips_val *val)
{
@@ -194,7 +253,6 @@ parse_test_gcm_init(void)
char *tmp;
uint32_t i;
-
for (i = 0; i < info.nb_vec_lines; i++) {
char *line = info.vec[i];
@@ -218,3 +276,94 @@ parse_test_gcm_init(void)
return 0;
}
+
+#ifdef RTE_HAS_JANSSON
+static int
+parse_test_gcm_json_writeback(struct fips_val *val)
+{
+ struct fips_val tmp_val;
+ json_t *tcId, *tag;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+
+ json_info.json_write_case = json_object();
+ json_object_set(json_info.json_write_case, "tcId", tcId);
+
+ if (info.op == FIPS_TEST_ENC_AUTH_GEN) {
+ json_t *ct;
+
+ tmp_val.val = val->val;
+ tmp_val.len = vec.pt.len;
+
+ writeback_hex_str("", info.one_line_text, &tmp_val);
+ ct = json_string(info.one_line_text);
+ json_object_set_new(json_info.json_write_case, CT_JSON_STR, ct);
+
+ if (info.interim_info.gcm_data.gen_iv) {
+ json_t *i
[v5, 06/11] examples/fips_validation: add json to hmac
From: Brandon Lo
Adds JSON support for the HMAC algorithm.
Signed-off-by: Brandon Lo
---
examples/fips_validation/fips_validation.c| 2 +
examples/fips_validation/fips_validation.h| 6 ++
.../fips_validation/fips_validation_hmac.c| 93 +++
examples/fips_validation/main.c | 3 +
4 files changed, 104 insertions(+)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 6594a15579..e8520f59cf 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -458,6 +458,8 @@ fips_test_parse_one_json_vector_set(void)
/* Vector sets contain the algorithm type, and nothing else we need. */
if (strstr(algo_str, "AES-GCM"))
info.algo = FIPS_TEST_ALGO_AES_GCM;
+ if (strstr(algo_str, "HMAC"))
+ info.algo = FIPS_TEST_ALGO_HMAC;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 8b9d528c53..3b3ffb7fa6 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -253,6 +253,12 @@ fips_test_parse_one_json_case(void);
int
parse_test_gcm_json_init(void);
+
+int
+parse_test_hmac_json_init(void);
+
+int
+parse_test_hmac_json_algorithm(void);
#endif /* RTE_HAS_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_hmac.c
b/examples/fips_validation/fips_validation_hmac.c
index 1285c9d283..4cd1b1ac07 100644
--- a/examples/fips_validation/fips_validation_hmac.c
+++ b/examples/fips_validation/fips_validation_hmac.c
@@ -19,6 +19,15 @@
#define PT_STR "Msg = "
#define TAG_STR"Mac = "
+#define ALGO_JSON_STR "algorithm"
+
+#define KEYLEN_JSON_STR"keyLen"
+#define TAGLEN_JSON_STR"macLen"
+
+#define KEY_JSON_STR "key"
+#define PT_JSON_STR"msg"
+#define TAG_JSON_STR "mac"
+
struct hash_size_conversion {
const char *str;
enum rte_crypto_auth_algorithm algo;
@@ -65,6 +74,29 @@ struct fips_test_callback hmac_tests_interim_vectors[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef RTE_HAS_JANSSON
+struct hash_size_conversion json_algorithms[] = {
+ {"HMAC-SHA-1", RTE_CRYPTO_AUTH_SHA1_HMAC},
+ {"HMAC-SHA2-224", RTE_CRYPTO_AUTH_SHA224_HMAC},
+ {"HMAC-SHA2-256", RTE_CRYPTO_AUTH_SHA256_HMAC},
+ {"HMAC-SHA2-384", RTE_CRYPTO_AUTH_SHA384_HMAC},
+ {"HMAC-SHA2-512", RTE_CRYPTO_AUTH_SHA512_HMAC},
+};
+
+struct fips_test_callback hmac_tests_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_hex_str, &vec.cipher_auth.key},
+ {PT_JSON_STR, parse_uint8_hex_str, &vec.pt},
+ {TAG_JSON_STR, parse_uint8_hex_str, &vec.cipher_auth.digest},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback hmac_tests_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_read_uint32_val, &vec.cipher_auth.key},
+ {TAGLEN_JSON_STR, parser_read_uint32_bit_val,
&vec.cipher_auth.digest},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+#endif /* RTE_HAS_JANSSON */
+
static int
parse_test_hmac_writeback(struct fips_val *val)
{
@@ -103,3 +135,64 @@ parse_test_hmac_init(void)
return 0;
}
+
+#ifdef RTE_HAS_JANSSON
+static int
+parse_test_hmac_json_writeback(struct fips_val *val)
+{
+ struct fips_val val_local;
+ json_t *tcId, *mac;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+
+ json_info.json_write_case = json_object();
+ json_object_set(json_info.json_write_case, "tcId", tcId);
+
+
+ val_local.val = val->val + vec.pt.len;
+ val_local.len = vec.cipher_auth.digest.len;
+
+ writeback_hex_str("", info.one_line_text, &val_local);
+
+ mac = json_string(info.one_line_text);
+ json_object_set_new(json_info.json_write_case, TAG_JSON_STR, mac);
+
+ return 0;
+}
+
+int
+parse_test_hmac_json_algorithm(void)
+{
+ json_t *algorithm_object;
+ const char *algorithm_str;
+ uint32_t i;
+
+ algorithm_object = json_object_get(json_info.json_vector_set,
"algorithm");
+ algorithm_str = json_string_value(algorithm_object);
+
+ for (i = 0; i < RTE_DIM(json_algorithms); i++) {
+ if (strstr(algorithm_str, json_algorithms[i].str)) {
+ info.interim_info.hmac_data.algo =
json_algorithms[i].algo;
+ return 0;
+ }
+ }
+
+ return -1;
+}
+
+int
+parse_test_hmac_json_init(void)
+{
+ info.op = FIPS_TEST_ENC_AUTH_GEN;
+ info.parse_writeback = parse_test_hmac_json_writeback;
+ info.callbacks = hmac_tests_json_vectors;
+ info.writeback_callbacks = NULL;
+ info.kat_check = rsp_test_hmac_check;
+ info.interim_callbacks = hmac_te
[v5, 07/11] examples/fips_validation: implement json cmac test
From: Brandon Lo
Implemented JSON support for the CMAC test.
Signed-off-by: Brandon Lo
--
v5:
* parser_read_cmac_direction_str is static.
---
examples/fips_validation/fips_validation.h| 3 +
.../fips_validation/fips_validation_cmac.c| 80 +++
2 files changed, 83 insertions(+)
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 3b3ffb7fa6..88cbb0303e 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -259,6 +259,9 @@ parse_test_hmac_json_init(void);
int
parse_test_hmac_json_algorithm(void);
+
+int
+parse_test_cmac_json_init(void);
#endif /* RTE_HAS_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_cmac.c
b/examples/fips_validation/fips_validation_cmac.c
index 54c951ef83..094e3922a4 100644
--- a/examples/fips_validation/fips_validation_cmac.c
+++ b/examples/fips_validation/fips_validation_cmac.c
@@ -32,6 +32,18 @@
#define PASS_STR "P"
#define FAIL_STR "F"
+#define KLEN_JSON_STR "keyLen"
+#define PTLEN_JSON_STR "msgLen"
+#define TAGLEN_JSON_STR"macLen"
+#define KEY_JSON_STR "key"
+#define PT_JSON_STR"message"
+#define TAG_JSON_STR "mac"
+#define DIRECTION_JSON_STR "direction"
+#define POS_NEG_JSON_STR "testPassed"
+
+#define GEN_JSON_STR "gen"
+#define VERIF_JSON_STR "ver"
+
struct hash_algo_conversion {
const char *str;
enum fips_test_algorithms algo;
@@ -39,6 +51,74 @@ struct hash_algo_conversion {
{"AES", FIPS_TEST_ALGO_AES_CMAC},
};
+#ifdef RTE_HAS_JANSSON
+static int
+parser_read_cmac_direction_str(__rte_unused const char *key, char *src,
+ __rte_unused struct fips_val *val)
+{
+ if (strcmp(src, "gen") == 0)
+ info.op = FIPS_TEST_ENC_AUTH_GEN;
+ else if (strcmp(src, "ver") == 0)
+ info.op = FIPS_TEST_DEC_AUTH_VERIF;
+
+ return 0;
+}
+
+struct fips_test_callback cmac_tests_interim_json_vectors[] = {
+ {KLEN_JSON_STR, parser_read_uint32_bit_val,
&vec.cipher_auth.key},
+ {PTLEN_JSON_STR, parser_read_uint32_bit_val, &vec.pt},
+ {TAGLEN_JSON_STR, parser_read_uint32_bit_val,
&vec.cipher_auth.digest},
+ {DIRECTION_JSON_STR, parser_read_cmac_direction_str, NULL},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback cmac_tests_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_hex_str, &vec.cipher_auth.key},
+ {PT_JSON_STR, parse_uint8_known_len_hex_str, &vec.pt},
+ {TAG_JSON_STR, parse_uint8_known_len_hex_str,
+ &vec.cipher_auth.digest},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+static int
+parse_test_cmac_json_writeback(struct fips_val *val)
+{
+ json_info.json_write_case = json_object();
+ json_object_set(json_info.json_write_case, "tcId",
+ json_object_get(json_info.json_test_case, "tcId"));
+
+ if (info.op == FIPS_TEST_ENC_AUTH_GEN) {
+ struct fips_val tmp_val = {val->val + vec.pt.len,
+ vec.cipher_auth.digest.len};
+
+ writeback_hex_str("", info.one_line_text, &tmp_val);
+ json_object_set_new(json_info.json_write_case, TAG_JSON_STR,
+ json_string(info.one_line_text));
+ } else {
+ if (vec.status == RTE_CRYPTO_OP_STATUS_SUCCESS)
+ json_object_set_new(json_info.json_write_case,
POS_NEG_JSON_STR,
+ json_boolean(true));
+ else if (vec.status == RTE_CRYPTO_OP_STATUS_AUTH_FAILED)
+ json_object_set_new(json_info.json_write_case,
POS_NEG_JSON_STR,
+ json_boolean(false));
+ }
+
+ return 0;
+}
+
+int
+parse_test_cmac_json_init(void)
+{
+ info.algo = FIPS_TEST_ALGO_AES_CMAC;
+
+ info.parse_writeback = parse_test_cmac_json_writeback;
+ info.callbacks = cmac_tests_json_vectors;
+ info.interim_callbacks = cmac_tests_interim_json_vectors;
+
+ return 0;
+}
+#endif /* RTE_HAS_JANSSON */
+
static int
parse_test_cmac_writeback(struct fips_val *val)
{
--
2.25.1
Re: [PATCH v3 1/2] app/testpmd: do not poll stopped queues
07/03/2022 13:53, Dmitry Kozlyuk:
> Calling Rx/Tx functions on a stopped queue is not supported.
> Do not run packet forwarding for streams that use stopped queues.
>
> Each stream has a read-only "disabled" field,
> so that lcore function can skip such streams.
> Forwarding engines can set this field
> using a new "stream_init" callback function
> by checking relevant queue states,
> which are stored along with queue configurations
> (not all PMDs implement rte_eth_rx/tx_queue_info_get()
> to query the state from there).
>
> Fixes: 5f4ec54f1d16 ("testpmd: queue start and stop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dmitry Kozlyuk
> Acked-by: Matan Azrad
This patch is waiting for long without any comment.
Applied in next-net, thanks.
[v5, 08/11] examples/fips_validation: add parsing for cmac
From: Brandon Lo
Added function to parse algorithm for CMAC test.
Signed-off-by: Brandon Lo
Signed-off-by: Gowrishankar Muthukrishnan
--
v5:
* parser_read_cmac_direction_str implementation moved to static.
---
examples/fips_validation/fips_validation.c | 19 ---
examples/fips_validation/main.c| 3 +++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index e8520f59cf..ab4c0d0eca 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -460,6 +460,8 @@ fips_test_parse_one_json_vector_set(void)
info.algo = FIPS_TEST_ALGO_AES_GCM;
if (strstr(algo_str, "HMAC"))
info.algo = FIPS_TEST_ALGO_HMAC;
+ if (strstr(algo_str, "CMAC"))
+ info.algo = FIPS_TEST_ALGO_AES_CMAC;
else
return -EINVAL;
@@ -470,7 +472,6 @@ int
fips_test_parse_one_json_group(void)
{
int ret, i;
- json_int_t val;
json_t *param;
if (info.interim_callbacks) {
@@ -478,8 +479,20 @@ fips_test_parse_one_json_group(void)
for (i = 0; info.interim_callbacks[i].key != NULL; i++) {
param = json_object_get(json_info.json_test_group,
info.interim_callbacks[i].key);
- val = json_integer_value(param);
- snprintf(json_value, 255, "%"JSON_INTEGER_FORMAT, val);
+ switch (json_typeof(param)) {
+ case JSON_STRING:
+ snprintf(json_value, 256, "%s",
json_string_value(param));
+ break;
+
+ case JSON_INTEGER:
+ snprintf(json_value, 255,
"%"JSON_INTEGER_FORMAT,
+ json_integer_value(param));
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
/* First argument is blank because the key
* is not included in the string being parsed.
*/
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 261e2c4c99..9df6abf47f 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -1945,6 +1945,9 @@ fips_test_one_test_group(void)
case FIPS_TEST_ALGO_HMAC:
ret = parse_test_hmac_json_init();
break;
+ case FIPS_TEST_ALGO_AES_CMAC:
+ ret = parse_test_cmac_json_init();
+ break;
default:
return -EINVAL;
}
--
2.25.1
[v5, 09/11] examples/fips_validation: cleanup bypass tests in response file
Remove garbage entries for bypassed tests in response file.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/main.c | 74 -
1 file changed, 35 insertions(+), 39 deletions(-)
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 9df6abf47f..e703a111da 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -804,7 +804,7 @@ prepare_aes_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
info.device_name, cipher_xform->key.length,
cipher_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -852,7 +852,7 @@ prepare_tdes_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
info.device_name, cipher_xform->key.length,
cipher_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -889,7 +889,7 @@ prepare_hmac_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -935,7 +935,7 @@ prepare_gcm_xform(struct rte_crypto_sym_xform *xform)
aead_xform->digest_length,
aead_xform->aad_length,
aead_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -980,7 +980,7 @@ prepare_gmac_xform(struct rte_crypto_sym_xform *xform)
info.device_name, auth_xform->key.length,
auth_xform->digest_length,
auth_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -1018,7 +1018,7 @@ prepare_cmac_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -1064,7 +1064,7 @@ prepare_ccm_xform(struct rte_crypto_sym_xform *xform)
aead_xform->digest_length,
aead_xform->aad_length,
aead_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -1099,7 +1099,7 @@ prepare_sha_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u digest length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -1139,7 +1139,7 @@ prepare_xts_xform(struct rte_crypto_sym_xform *xform)
RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
info.device_name, cipher_xform->key.length,
cipher_xform->iv.length);
- return -EPERM;
+ return -ENOTSUP;
}
return 0;
@@ -1254,7 +1254,7 @@ fips_generic_test(void)
ret = fips_run_test();
if (ret < 0) {
- if (ret == -EPERM || ret == -ENOTSUP) {
+ if (ret == -ENOTSUP) {
fprintf(info.fp_wr, "Bypass\n\n");
return 0;
}
@@ -1289,7 +1289,7 @@ fips_generic_test(void)
fprintf(info.fp_wr, "\n");
free(val.val);
- return 0;
+ return 1;
}
static int
@@ -1458,7 +1458,7 @@ fips_mct_tdes_test(void)
free(val.val);
- return 0;
+ return 1;
}
static int
@@ -1537,7 +1537,7 @@ fips_mct_aes_ecb_test(void)
free(val.val);
- return 0;
+ return 1;
}
static int
fips_mct_aes_test(void)
@@ -1645,7 +1645,7 @@ fips_mct_aes_test(void)
free(val.val);
- return 0;
+ return 1;
}
static int
@@ -1731,7 +1731,7 @@ fips_mct_sha_test(void)
free(val.val);
- return 0;
+ return 1;
}
@@ -1846,18 +1846,15 @@ fips_test_one_file(void)
}
ret = fips_test_parse_one_case();
- switch (ret) {
- case 0:
- ret = test_ops.test();
- if (ret == 0)
-
[v5, 10/11] examples/fips_validation: reset IV generation in every test group
Reset IV generation in every test group.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation_gcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/examples/fips_validation/fips_validation_gcm.c
b/examples/fips_validation/fips_validation_gcm.c
index 3604b21f13..7e89f2a6b2 100644
--- a/examples/fips_validation/fips_validation_gcm.c
+++ b/examples/fips_validation/fips_validation_gcm.c
@@ -344,6 +344,7 @@ parse_test_gcm_json_init(void)
direction_obj = json_object_get(json_info.json_test_group,
DIR_JSON_STR);
direction_str = json_string_value(direction_obj);
+ info.interim_info.gcm_data.gen_iv = 0;
if (strcmp(direction_str, OP_ENC_JSON_STR) == 0) {
json_t *ivGen_obj = json_object_get(json_info.json_test_group,
IVGEN_JSON_STR);
--
2.25.1
[v5, 11/11] examples/fips_validation: add parsing for aes_cbc
Added function to parse algorithm for AES_CBC test.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation.c| 8 +-
examples/fips_validation/fips_validation.h| 4 +
.../fips_validation/fips_validation_aes.c | 223 ++
examples/fips_validation/main.c | 73 --
4 files changed, 281 insertions(+), 27 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index ab4c0d0eca..8cec172a5f 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -120,7 +120,7 @@ fips_test_parse_header(void)
for (i = 0; i < info.nb_vec_lines; i++) {
if (!algo_parsed) {
- if (strstr(info.vec[i], "AESVS")) {
+ if (strstr(info.vec[i], "AES")) {
algo_parsed = 1;
info.algo = FIPS_TEST_ALGO_AES;
ret = parse_test_aes_init();
@@ -458,10 +458,12 @@ fips_test_parse_one_json_vector_set(void)
/* Vector sets contain the algorithm type, and nothing else we need. */
if (strstr(algo_str, "AES-GCM"))
info.algo = FIPS_TEST_ALGO_AES_GCM;
- if (strstr(algo_str, "HMAC"))
+ else if (strstr(algo_str, "HMAC"))
info.algo = FIPS_TEST_ALGO_HMAC;
- if (strstr(algo_str, "CMAC"))
+ else if (strstr(algo_str, "CMAC"))
info.algo = FIPS_TEST_ALGO_AES_CMAC;
+ else if (strstr(algo_str, "AES-CBC"))
+ info.algo = FIPS_TEST_ALGO_AES;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 88cbb0303e..6385ec4d8d 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -103,6 +103,7 @@ enum fips_aesavs_test_types {
AESAVS_TYPE_VARTXT,
AESAVS_TYPE_MMT,
AESAVS_TYPE_MCT,
+ AESAVS_TYPE_AFT,
};
enum fips_tdes_test_types {
@@ -262,6 +263,9 @@ parse_test_hmac_json_algorithm(void);
int
parse_test_cmac_json_init(void);
+
+int
+parse_test_aes_json_init(void);
#endif /* RTE_HAS_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_aes.c
b/examples/fips_validation/fips_validation_aes.c
index b3c5e31f32..f935217f34 100644
--- a/examples/fips_validation/fips_validation_aes.c
+++ b/examples/fips_validation/fips_validation_aes.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include "fips_validation.h"
@@ -25,6 +26,19 @@
#define OP_ENC_STR "ENCRYPT"
#define OP_DEC_STR "DECRYPT"
+#define ALGO_JSON_STR "algorithm"
+#define TESTTYPE_JSON_STR "testType"
+#define DIR_JSON_STR "direction"
+#define KEYLEN_JSON_STR"keyLen"
+
+#define KEY_JSON_STR "key"
+#define IV_JSON_STR"iv"
+#define PT_JSON_STR"pt"
+#define CT_JSON_STR"ct"
+
+#define OP_ENC_JSON_STR"encrypt"
+#define OP_DEC_JSON_STR"decrypt"
+
struct {
uint32_t type;
const char *desc;
@@ -37,6 +51,7 @@ struct {
{TDES_VARIABLE_TEXT, "KAT"},
{AESAVS_TYPE_MMT, "MMT"},
{AESAVS_TYPE_MCT, "MCT"},
+ {AESAVS_TYPE_AFT, "AFT"},
};
struct aes_test_algo {
@@ -92,6 +107,214 @@ struct fips_test_callback aes_writeback_callbacks[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef RTE_HAS_JANSSON
+struct fips_test_callback aes_dec_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {IV_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {CT_JSON_STR, parse_uint8_hex_str, &vec.ct},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback aes_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_read_uint32_bit_val,
&vec.cipher_auth.key},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback aes_enc_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {IV_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {PT_JSON_STR, parse_uint8_hex_str, &vec.pt},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+static int
+parse_test_aes_json_writeback(struct fips_val *val)
+{
+ struct fips_val tmp_val;
+ json_t *tcId;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+
+ json_info.json_write_case = json_object();
+ json_object_set(json_info.json_write_case, "tcId", tcId);
+
+ if (info.op == FIPS_TEST_ENC_AUTH_GEN) {
+ json_t *ct;
+
+ tmp_val.val = val->val;
+ tmp_val.len = vec.pt.len;
+
+ writeback_hex_str("", info.one_line_text, &tmp_val);
+ ct = json_string(info.one_line
Re: [RFT v2 1/3] random: add rte_rand_float()
On Wed, 25 May 2022 14:45:37 + Mattias Rönnblom wrote: > I would call it something else than "float", in particular since it > doesn't return "float" but a "double" type floating point value. > > rte_drand() maybe? Short, but might be confused with rte_rand(), given > the visual similarity. I still I would still prefer that over > rte_rand_double(). The corresponding standard library routine is drand48(). With that convention it would be rte_drand().
[dpdk-dev v3] crypto/qat: use intel-ipsec-mb for partial hash & aes
Since openssl 3.0 now deprecates the low level API QAT required to
perform partial hash & aes operation when creating the session. This
patch add in qat_ipsec_mb_lib driver parameter to allow QAT PMD to
switch APIs between openssl and intel ipsec-mb library.
Signed-off-by: Kai Ji
Signed-off-by: Fan Zhang
---
doc/guides/cryptodevs/qat.rst| 13 +
drivers/common/qat/meson.build | 7 +
drivers/common/qat/qat_device.c | 1 +
drivers/common/qat/qat_device.h | 1 +
drivers/crypto/qat/qat_sym.c | 3 +
drivers/crypto/qat/qat_sym_session.c | 507 ---
6 files changed, 489 insertions(+), 43 deletions(-)
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 785e041324..d92409b77e 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -287,6 +287,19 @@ by comma. When the same parameter is used more than once
first occurrence of the
is used.
Maximum threshold that can be set is 32.
+Running QAT PMD with Intel IPSEC MB library for symmetric precomputes function
+~~
+
+The QAT PMD use Openssl library for partial hash calculation in symmetirc
precomputes function by
+default, the following parameter is allow QAT PMD switch over to multi-buffer
job API if Intel
+IPSEC MB library installed on system.
+
+- qat_ipsec_mb_lib
+
+To use this feature the user must set the parameter on process start as a
device additional parameter::
+
+ -a 03:01.1,qat_ipsec_mb_lib=1
+
Device and driver naming
diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build
index b7027f3164..bba75b5194 100644
--- a/drivers/common/qat/meson.build
+++ b/drivers/common/qat/meson.build
@@ -35,6 +35,13 @@ if qat_crypto and not libcrypto.found()
'missing dependency, libcrypto')
endif
+IMB_required_ver = '1.0.0'
+libipsecmb = cc.find_library('IPSec_MB', required: false)
+if libipsecmb.found()
+ext_deps += libipsecmb
+dpdk_conf.set('RTE_QAT_LIBIPSECMB', true)
+endif
+
# The driver should not build if both compression and crypto are disabled
#FIXME common code depends on compression files so check only compress!
if not qat_compress # and not qat_crypto
diff --git a/drivers/common/qat/qat_device.c b/drivers/common/qat/qat_device.c
index 6824d97050..db4b087d2b 100644
--- a/drivers/common/qat/qat_device.c
+++ b/drivers/common/qat/qat_device.c
@@ -364,6 +364,7 @@ static int qat_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
struct qat_pci_device *qat_pci_dev;
struct qat_dev_hw_spec_funcs *ops_hw;
struct qat_dev_cmd_param qat_dev_cmd_param[] = {
+ { QAT_IPSEC_MB_LIB, 0 },
{ SYM_ENQ_THRESHOLD_NAME, 0 },
{ ASYM_ENQ_THRESHOLD_NAME, 0 },
{ COMP_ENQ_THRESHOLD_NAME, 0 },
diff --git a/drivers/common/qat/qat_device.h b/drivers/common/qat/qat_device.h
index 85fae7b7c7..e1a32a7e87 100644
--- a/drivers/common/qat/qat_device.h
+++ b/drivers/common/qat/qat_device.h
@@ -16,6 +16,7 @@
#define QAT_DEV_NAME_MAX_LEN 64
+#define QAT_IPSEC_MB_LIB "qat_ipsec_mb_lib"
#define SYM_ENQ_THRESHOLD_NAME "qat_sym_enq_threshold"
#define ASYM_ENQ_THRESHOLD_NAME "qat_asym_enq_threshold"
#define COMP_ENQ_THRESHOLD_NAME "qat_comp_enq_threshold"
diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
index ca8c9a8124..3477cd89ad 100644
--- a/drivers/crypto/qat/qat_sym.c
+++ b/drivers/crypto/qat/qat_sym.c
@@ -15,6 +15,7 @@
#include "qat_qp.h"
uint8_t qat_sym_driver_id;
+int qat_ipsec_mb_lib;
struct qat_crypto_gen_dev_ops qat_sym_gen_dev_ops[QAT_N_GENS];
@@ -307,6 +308,8 @@ qat_sym_dev_create(struct qat_pci_device *qat_pci_dev,
if (!strcmp(qat_dev_cmd_param[i].name, SYM_ENQ_THRESHOLD_NAME))
internals->min_enq_burst_threshold =
qat_dev_cmd_param[i].val;
+ if (!strcmp(qat_dev_cmd_param[i].name, QAT_IPSEC_MB_LIB))
+ qat_ipsec_mb_lib = qat_dev_cmd_param[i].val;
i++;
}
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index 9d6a19c0be..fd3f38167d 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -7,6 +7,10 @@
#include/* Needed to calculate pre-compute values */
#include/* Needed for bpi runt block processing */
+#ifdef RTE_QAT_LIBIPSECMB
+#include
+#endif
+
#include
#include
#include
@@ -22,6 +26,12 @@
#include "qat_sym_session.h"
#include "qat_sym.h"
+#if (OPENSSL_VERSION_NUMBER >= 0x3000L)
+#include
+#endif
+
+extern int qat_ipsec_mb_lib;
+
/* SHA1 - 20 bytes - Initialiser state can be found in FIPS stds 180-2 */
static const uint8_t sha1InitialState[] = {
0x67, 0x45, 0x23, 0x01, 0xef, 0xcd, 0xab, 0x89
RE: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotplug
> -Original Message- > From: Zhang, Qi Z > Sent: Wednesday, May 11, 2022 9:27 PM > To: Jeff Daly ; dev@dpdk.org > Cc: sta...@dpdk.org; Stephen Douthit > Subject: RE: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on > hotplug > > Caution: This is an external email. Please take care when clicking links or > opening attachments. > > > > -Original Message- > > From: Jeff Daly > > Sent: Wednesday, April 13, 2022 1:42 AM > > To: dev@dpdk.org > > Cc: sta...@dpdk.org; Stephen Douthit ; > Wang, > > Haiyue > > Subject: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on > > hotplug > > > > Currently the ixgbe driver does not ID any SFP except for the first > > one plugged in. This can lead to no-link, or incorrect speed conditions. > > Does kernel driver has the same issue for this? > No, the kernel driver does the correct thing. > > > > For example: > > > > * If link is initially established with a 1G SFP, and later a 1G/10G > > multispeed part is later installed, then the MAC link setup functions > > are never called to change from 1000BASE-X to 10GBASE-R mode, and the > > link stays running at the slower rate. > > > > * If link is initially established with a 1G SFP, and later a 10G only > > module is later installed, no link is established, since we are still > > trasnsmitting in 1000BASE-X mode to a 10GBASE-R only partner. > > > > Refactor the SFP ID/setup, and link setup code, to more closely match > > the flow of the mainline kernel driver which does not have these > > issues. In that driver a service task runs periodically to handle > > these operations based on bit flags that have been set (usually via > > interrupt or userspace request), and then get cleared once the requested > subtask has been completed. > > If kernel driver don't have this issue, Is this the same way that kernel > driver > handle this issue? > The history can probably be searched back for, but yes the mechanism implemented in this patch tries to follow the kernel's method for handling hotplug. The patch has been split into 3 chunks, starting with: https://patchwork.dpdk.org/project/dpdk/patch/ffbdaf3aa487241a51bb6512bbb4701da17e69fe.1652988826.git.je...@silicom-usa.com/ it was refactored according to the wishes of the prior maintainer, so it's not exactly the same as this one which is why it was submitted as a new one, not a revision of this. HTH. > Btw, could you break down the patch for easy review? > > Thanks > Qi
[PATCH v2 00/14] cryptodev: rsa, dh, ecdh changes
This patchset introduces some of changes discussed on mailing list for 22.07 release in cryptodev asym. Key changes: - It fixes API for RSA (expescially signature paddings) - Adds Elliptic-Curve Diffie-Hellman - Adds Eliiptic-Curve point verification - Adds RSA missing padding fields - Adds asym op flags - Fixes many API comments (like EC curves) - Clarifies usage of NONE padding for singatures v2: - squashed commits - added capabilities - implemented sugestions from the mailing list Arek Kusztal (14): cryptodev: redefine ec group enum cryptodev: reduce number of comments in asym xform cryptodev: separate key exchange operation enum cryptodev: remove comment about using ephemeral key in dsa cryptodev: clarify usage of private key in dh cryptodev: move dh type from xform to dh op cryptodev: add elliptic curve diffie hellman cryptodev: add public key verify option cryptodev: add asym op flags cryptodev: clarify usage of rsa padding hash cryptodev: move RSA padding into separate struct cryptodev: clarify rsa verify with none padding cryptodev: add salt length and optional label cryptodev: add asym algorithms capabilities app/test-crypto-perf/main.c | 12 +- app/test-eventdev/test_perf_common.c | 2 +- app/test/test_cryptodev_asym.c | 234 - app/test/test_event_crypto_adapter.c | 16 +- drivers/common/cpt/cpt_ucode_asym.h | 4 +- drivers/crypto/cnxk/cnxk_ae.h| 8 +- drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +- drivers/crypto/openssl/rte_openssl_pmd.c | 17 +- drivers/crypto/openssl/rte_openssl_pmd_ops.c | 155 --- drivers/crypto/qat/dev/qat_asym_pmd_gen1.c | 68 - drivers/crypto/qat/qat_asym.c| 12 +- lib/cryptodev/rte_crypto_asym.h | 375 ++- lib/cryptodev/rte_cryptodev.c| 96 ++- lib/cryptodev/rte_cryptodev.h| 75 +- lib/cryptodev/version.map| 4 + 15 files changed, 742 insertions(+), 340 deletions(-) -- 2.13.6
[PATCH v2 01/14] cryptodev: redefine ec group enum
- EC enum was renamed to rte_crypto_curve_id.
Elliptic curve enum name was incorrectly associated
with group (it comes from current tls registry name).
- Clarified comments about TLS deprecation.
Some curves included are deprecated with TLS 1.3.
Comments to address it were added.
- Clarified FFDH groups usage.
Elliptic curves IDs in TLS are placed in the same registry
as FFDH. Cryptodev does not assign specific groups, and
if specific groups would be assigned by DPDK, it cannot be
TLS SupportedGroups registry, as it would conflict with
other protocols like IPSec.
- Added IANA reference.
Only few selected curves are included in previously
referenced rfc8422. IANA reference is added instead.
- Removed UNKNOWN ec group.
There is no default value, and there is no UNKNOWN
elliptic curve.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index cd24d4b07b..7206652458 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -38,16 +38,20 @@ extern const char *
rte_crypto_asym_op_strings[];
/**
- * TLS named curves
- * https://tools.ietf.org/html/rfc8422
+ * List of elliptic curves. This enum aligns with
+ * TLS "Supported Groups" registry (previously known as
+ * NamedCurve registry). FFDH groups are not, and will not
+ * be included in this list.
+ * Deprecation for selected curve in tls does not deprecate
+ * the selected curve in Cryptodev.
+ * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
*/
-enum rte_crypto_ec_group {
- RTE_CRYPTO_EC_GROUP_UNKNOWN = 0,
+enum rte_crypto_curve_id {
RTE_CRYPTO_EC_GROUP_SECP192R1 = 19,
RTE_CRYPTO_EC_GROUP_SECP224R1 = 21,
RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
- RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
+ RTE_CRYPTO_EC_GROUP_SECP521R1 = 25
};
/**
@@ -294,7 +298,7 @@ struct rte_crypto_dsa_xform {
*
*/
struct rte_crypto_ec_xform {
- enum rte_crypto_ec_group curve_id;
+ enum rte_crypto_curve_id curve_id;
/**< Pre-defined ec groups */
};
--
2.13.6
[PATCH v2 02/14] cryptodev: reduce number of comments in asym xform
- Reduced number of comments in asymmetric xform.
Information describing basic functionality of well known
algorithms are unnecessary.
- Removed NONE asymetric xform.
Signed-off-by: Arek Kusztal
---
app/test/test_cryptodev_asym.c | 2 -
lib/cryptodev/rte_crypto_asym.h | 114
lib/cryptodev/rte_cryptodev.c | 1 -
3 files changed, 46 insertions(+), 71 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 573af2a537..5aa9d65395 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -288,7 +288,6 @@ test_cryptodev_asym_ver(struct rte_crypto_op *op,
break;
case RTE_CRYPTO_ASYM_XFORM_DH:
case RTE_CRYPTO_ASYM_XFORM_DSA:
- case RTE_CRYPTO_ASYM_XFORM_NONE:
case RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED:
default:
break;
@@ -440,7 +439,6 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym
*ts_params,
break;
case RTE_CRYPTO_ASYM_XFORM_DH:
case RTE_CRYPTO_ASYM_XFORM_DSA:
- case RTE_CRYPTO_ASYM_XFORM_NONE:
case RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED:
default:
snprintf(test_msg, ASYM_TEST_MSG_LEN,
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 7206652458..66ffb29743 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -38,6 +38,40 @@ extern const char *
rte_crypto_asym_op_strings[];
/**
+ * Buffer to hold crypto params required for asym operations.
+ *
+ * These buffers can be used for both input to PMD and output from PMD. When
+ * used for output from PMD, application has to ensure the buffer is large
+ * enough to hold the target data.
+ *
+ * If an operation requires the PMD to generate a random number,
+ * and the device supports CSRNG, 'data' should be set to NULL.
+ * The crypto parameter in question will not be used by the PMD,
+ * as it is internally generated.
+ */
+typedef struct rte_crypto_param_t {
+ uint8_t *data;
+ /**< pointer to buffer holding data */
+ rte_iova_t iova;
+ /**< IO address of data buffer */
+ size_t length;
+ /**< length of data in bytes */
+} rte_crypto_param;
+
+/** Unsigned big-integer in big-endian format */
+typedef rte_crypto_param rte_crypto_uint;
+
+/**
+ * Structure for elliptic curve point
+ */
+struct rte_crypto_ec_point {
+ rte_crypto_param x;
+ /**< X coordinate */
+ rte_crypto_param y;
+ /**< Y coordinate */
+};
+
+/**
* List of elliptic curves. This enum aligns with
* TLS "Supported Groups" registry (previously known as
* NamedCurve registry). FFDH groups are not, and will not
@@ -55,46 +89,23 @@ enum rte_crypto_curve_id {
};
/**
- * Asymmetric crypto transformation types.
- * Each xform type maps to one asymmetric algorithm
- * performing specific operation
- *
+ * Asymmetric crypto algorithms
*/
enum rte_crypto_asym_xform_type {
- RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
+ RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED,
/**< Invalid xform. */
- RTE_CRYPTO_ASYM_XFORM_NONE,
- /**< Xform type None.
-* May be supported by PMD to support
-* passthrough op for debugging purpose.
-* if xform_type none , op_type is disregarded.
-*/
RTE_CRYPTO_ASYM_XFORM_RSA,
- /**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
-* Refer to rte_crypto_asym_op_type
-*/
+ /**< RSA */
RTE_CRYPTO_ASYM_XFORM_DH,
- /**< Diffie-Hellman.
-* Performs Key Generate and Shared Secret Compute.
-* Refer to rte_crypto_asym_op_type
-*/
+ /**< Diffie-Hellman */
RTE_CRYPTO_ASYM_XFORM_DSA,
- /**< Digital Signature Algorithm
-* Performs Signature Generation and Verification.
-* Refer to rte_crypto_asym_op_type
-*/
+ /**< Digital Signature Algorithm */
RTE_CRYPTO_ASYM_XFORM_MODINV,
- /**< Modular Multiplicative Inverse
-* Perform Modular Multiplicative Inverse b^(-1) mod n
-*/
+ /**< Modular Multiplicative Inverse */
RTE_CRYPTO_ASYM_XFORM_MODEX,
- /**< Modular Exponentiation
-* Perform Modular Exponentiation b^e mod n
-*/
+ /**< Modular Exponentiation */
RTE_CRYPTO_ASYM_XFORM_ECDSA,
- /**< Elliptic Curve Digital Signature Algorithm
-* Perform Signature Generation and Verification.
-*/
+ /**< Elliptic Curve Digital Signature Algorithm */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -126,11 +137,12 @@ enum rte_crypto_asym_op_type {
* Padding types for RSA signature.
*/
enum rte_crypto_rsa_padding_type {
- RTE_CRYPTO_RSA_PADDING_NONE = 0,
+ RTE_CRYPTO_RSA_PADDING_NONE,
/**< RSA no padding scheme */
RTE_CRYPTO_RSA_PADDING_P
[PATCH v2 03/14] cryptodev: separate key exchange operation enum
- Separated key exchange enum from asym op type.
Key exchange and asymmetric crypto operations like signatures,
encryption/decryption should not share same operation enum as
its use cases are unrelated and mutually exclusive.
Therefore op_type was separate into:
1) operation type
2) key exchange operation type
Signed-off-by: Arek Kusztal
---
app/test/test_cryptodev_asym.c | 11 +++
drivers/crypto/openssl/rte_openssl_pmd.c | 10 +++
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 12
lib/cryptodev/rte_crypto_asym.h | 45 +---
lib/cryptodev/rte_cryptodev.c| 14 ++---
5 files changed, 55 insertions(+), 37 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 5aa9d65395..1b77aa2b6a 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1062,7 +1062,7 @@ test_dh_gen_shared_sec(struct rte_crypto_asym_xform *xfrm)
asym_op = op->asym;
/* Setup a xform and op to generate private key only */
- xform.dh.type = RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
+ xform.dh.type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
xform.next = NULL;
asym_op->dh.priv_key.data = dh_test_params.priv_key.data;
asym_op->dh.priv_key.length = dh_test_params.priv_key.length;
@@ -1144,7 +1144,7 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform *xfrm)
asym_op = op->asym;
/* Setup a xform and op to generate private key only */
- xform.dh.type = RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE;
+ xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
xform.next = NULL;
asym_op->dh.priv_key.data = output;
asym_op->dh.priv_key.length = sizeof(output);
@@ -1227,7 +1227,7 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
* using test private key
*
*/
- xform.dh.type = RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE;
+ xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
xform.next = NULL;
asym_op->dh.pub_key.data = output;
@@ -1317,9 +1317,10 @@ test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
/* Setup a xform chain to generate
* private key first followed by
* public key
-*/xform.dh.type = RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE;
+*/
+ xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
- pub_key_xform.dh.type = RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE;
+ pub_key_xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
xform.next = &pub_key_xform;
asym_op->dh.pub_key.data = out_pub_key;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
b/drivers/crypto/openssl/rte_openssl_pmd.c
index d80e1052e2..2a3930df0a 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1697,7 +1697,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
int ret = 0;
if (sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE)) {
+ (1 << RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE)) {
/* compute shared secret using peer public key
* and current private key
* shared secret = peer_key ^ priv_key mod p
@@ -1754,9 +1754,9 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
* then first set DH with user provided private key
*/
if ((sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE)) &&
+ (1 << RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE)) &&
!(sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE))) {
+ (1 << RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE))) {
/* generate public key using user-provided private key
* pub_key = g ^ priv_key mod p
*/
@@ -1790,7 +1790,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
return 0;
}
- if (sess->u.dh.key_op & (1 << RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE)) {
+ if (sess->u.dh.key_op & (1 << RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE)) {
const BIGNUM *pub_key = NULL;
OPENSSL_LOG(DEBUG, "%s:%d update public key\n",
@@ -1805,7 +1805,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
}
if (sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE)) {
+ (1 << RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE)) {
const BIGNUM *priv_key = NULL;
OPENSSL_LOG(DEBUG, "%s:%d updated priv key\n",
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 1cb07794bd..c975ef640a 100644
--- a/drivers/
[PATCH v2 04/14] cryptodev: remove comment about using ephemeral key in dsa
- Removed comment that stated dsa can be used with Diffie
Hellman ephemeral key.
DH and DSA integration allowed to use ephemeral keys for
random integer but not for private keys.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 2b427afa3f..ef8686fda8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -270,13 +270,7 @@ struct rte_crypto_dsa_xform {
rte_crypto_uint g;
/**< Generator of the subgroup */
rte_crypto_uint x;
- /**< x: Private key of the signer in octet-string network
-* byte order format.
-* Used when app has pre-defined private key.
-* Valid only when xform chain is DSA ONLY.
-* if xform chain is DH private key generate + DSA, then DSA sign
-* compute will use internally generated key.
-*/
+ /**< x: Private key of the signer */
};
/**
--
2.13.6
[PATCH v2 05/14] cryptodev: clarify usage of private key in dh
- Clarified usage of private key in Diffie-Hellman.
CSRNG capable device should generate private key and then
use it for public key generation.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index ef8686fda8..1a77a74478 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -394,6 +394,11 @@ struct rte_crypto_dh_op_param {
* Input - private key, when xform type is one of:
* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+*
+* In case priv_key.length is 0 and xform type is set with
+* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+* device will generate private key and use it for public
+* key generation.
*/
rte_crypto_uint shared_secret;
--
2.13.6
[PATCH v2 06/14] cryptodev: move dh type from xform to dh op
- Moved dh operation type to dh operation struct.
Operation type (PUBLIC_KEY_GENERATION, SHARED_SECRET) should
be free to choose for any operation. One xform/session should
be enough to perform both DH operations, if op_type would be xform
member, session would have to be to be created twice for the same
group. Similar problem would be observed in sessionless case.
Additionally, it will help extend DH to support Elliptic Curves.
- Changed order of Diffie-Hellman operation phases.
Now it corresponds with the order of operations.
Signed-off-by: Arek Kusztal
---
app/test/test_cryptodev_asym.c | 11 +--
drivers/crypto/openssl/rte_openssl_pmd.c | 15 ++-
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 27 ---
lib/cryptodev/rte_crypto_asym.h | 22 ++
4 files changed, 21 insertions(+), 54 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 1b77aa2b6a..a151051165 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1062,8 +1062,8 @@ test_dh_gen_shared_sec(struct rte_crypto_asym_xform *xfrm)
asym_op = op->asym;
/* Setup a xform and op to generate private key only */
- xform.dh.type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
xform.next = NULL;
+ asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
asym_op->dh.priv_key.data = dh_test_params.priv_key.data;
asym_op->dh.priv_key.length = dh_test_params.priv_key.length;
asym_op->dh.pub_key.data = (uint8_t *)peer;
@@ -1144,8 +1144,8 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform *xfrm)
asym_op = op->asym;
/* Setup a xform and op to generate private key only */
- xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
xform.next = NULL;
+ asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
asym_op->dh.priv_key.data = output;
asym_op->dh.priv_key.length = sizeof(output);
@@ -1227,9 +1227,9 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
* using test private key
*
*/
- xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
xform.next = NULL;
+ asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
asym_op->dh.pub_key.data = output;
asym_op->dh.pub_key.length = sizeof(output);
/* load pre-defined private key */
@@ -1318,15 +1318,14 @@ test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
* private key first followed by
* public key
*/
- xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
- pub_key_xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
xform.next = &pub_key_xform;
+ asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
asym_op->dh.pub_key.data = out_pub_key;
asym_op->dh.pub_key.length = sizeof(out_pub_key);
asym_op->dh.priv_key.data = out_prv_key;
- asym_op->dh.priv_key.length = sizeof(out_prv_key);
+ asym_op->dh.priv_key.length = 0;
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool,
&sess);
if (ret < 0) {
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
b/drivers/crypto/openssl/rte_openssl_pmd.c
index 2a3930df0a..4e11770864 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1692,12 +1692,12 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
struct openssl_asym_session *sess)
{
struct rte_crypto_dh_op_param *op = &cop->asym->dh;
+ struct rte_crypto_asym_op *asym_op = cop->asym;
DH *dh_key = sess->u.dh.dh_key;
BIGNUM *priv_key = NULL;
int ret = 0;
- if (sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE)) {
+ if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE) {
/* compute shared secret using peer public key
* and current private key
* shared secret = peer_key ^ priv_key mod p
@@ -1753,10 +1753,8 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
* if user provides private key,
* then first set DH with user provided private key
*/
- if ((sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE)) &&
- !(sess->u.dh.key_op &
- (1 << RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE))) {
+ if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE &&
+ op->priv_key.length) {
/* generate public key using user-provided private key
* pub_key = g ^ priv_key mod p
*/
@@ -1790,7 +1788,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
re
[PATCH v2 07/14] cryptodev: add elliptic curve diffie hellman
- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 38 ++
1 file changed, 38 insertions(+)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index ffb0e8ed17..0dab7c0593 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -112,6 +112,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
+ RTE_CRYPTO_ASYM_XFORM_ECDH,
+ /**< Elliptic Curve Diffie Hellman */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
/**< End of list */
};
@@ -407,6 +409,42 @@ struct rte_crypto_dh_op_param {
};
/**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ * @note:
+ */
+struct rte_crypto_ecdh_op_param {
+ enum rte_crypto_asym_ke_type op_type;
+ /**< Key exchange operation type */
+ rte_crypto_uint priv_key;
+ /**<
+* Output - generated private key, when xform type is
+* RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+*
+* Input - private key, when xform type is one of:
+* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+*
+* In case priv_key.length is 0 and xform type is set with
+* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+* device will generate private key and use it for public
+* key generation.
+*/
+ struct rte_crypto_ec_point pub_key;
+ /**<
+* Output - generated public key, when xform type is
+* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+*
+* Input - peer's public key, when xform type is
+* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+*/
+ struct rte_crypto_ec_point shared_secret;
+ /**<
+* Output - calculated shared secret when xform type is
+* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+*/
+};
+
+/**
* DSA Operations params
*
*/
--
2.13.6
[PATCH v2 08/14] cryptodev: add public key verify option
- Added key exchange public key verify option.
For some elliptic curves public point in DH exchange
needs to be checked, if it lays on the curve.
Modular exponentiation needs certain checks as well, though
mathematically much easier.
This commit adds verify option to asym_op operations.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 9 ++---
lib/cryptodev/rte_cryptodev.c | 3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 0dab7c0593..3eafaecbbe 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -141,8 +141,10 @@ enum rte_crypto_asym_ke_type {
/**< Private Key generation operation */
RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
/**< Public Key generation operation */
- RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+ RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE,
/**< Shared Secret compute operation */
+ RTE_CRYPTO_ASYM_KE_EC_PUBLIC_KEY_VERIFY,
+ /**< Public Key Verification */
};
/**
@@ -434,8 +436,9 @@ struct rte_crypto_ecdh_op_param {
* Output - generated public key, when xform type is
* RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
*
-* Input - peer's public key, when xform type is
-* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+* Input - peer's public key, when xform type is one of:
+* RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE,
+* RTE_CRYPTO_ASYM_KE_EC_PUBLIC_KEY_VERIFY.
*/
struct rte_crypto_ec_point shared_secret;
/**<
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index af58f49d07..57ee6b3f07 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -185,7 +185,8 @@ const char *rte_crypto_asym_op_strings[] = {
const char *rte_crypto_asym_ke_strings[] = {
[RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE] = "priv_key_generate",
[RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE] = "pub_key_generate",
- [RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute"
+ [RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
+ [RTE_CRYPTO_ASYM_KE_EC_PUBLIC_KEY_VERIFY] = "pub_ec_key_verify"
};
/**
--
2.13.6
[PATCH v2 09/14] cryptodev: add asym op flags
- Added flags to rte_crypto_asym_op struct.
It may be shared between different algorithms.
- Added Diffie-Hellman padding flags.
Diffie-Hellman padding is used in certain protocols,
in others, leading zero bytes need to be stripped.
Even same protocol may use a different approach - most
glaring example is TLS1.2 - TLS1.3.
For ease of use, and to avoid additional copy
on certain occasions, driver should be able to return both.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 3eafaecbbe..1a57c0c532 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -75,6 +75,19 @@ struct rte_crypto_ec_point {
/**< Y coordinate */
};
+#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDINGRTE_BIT32(0)
+/**<
+ * If set to 1 - public key will be returned
+ * without leading zero bytes, otherwise it will be
+ * padded to the left with zero bytes (default)
+ */
+#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING RTE_BIT32(1)
+/**<
+ * If set to 1 - shared key will be returned
+ * without leading zero bytes, otherwise it will be
+ * padded to the left with zero bytes (default)
+ */
+
/**
* List of elliptic curves. This enum aligns with
* TLS "Supported Groups" registry (previously known as
@@ -589,6 +602,8 @@ struct rte_crypto_asym_op {
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
};
+ uint16_t flags;
+ /**< Asymmetric crypto operation flags */
};
#ifdef __cplusplus
--
2.13.6
[PATCH v2 10/14] cryptodev: clarify usage of rsa padding hash
- Clarified usage of RSA padding hash.
It was not specified how to use hash for PKCS1_5
padding. This could lead to incorrect implementation.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 1a57c0c532..1758aaa875 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -371,10 +371,27 @@ struct rte_crypto_rsa_op_param {
/**< RSA padding scheme to be used for transform */
enum rte_crypto_auth_algorithm md;
- /**< Hash algorithm to be used for data hash if padding
-* scheme is either OAEP or PSS. Valid hash algorithms
-* are:
-* MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+ /**<
+* RSA padding hash function
+*
+* When a specific padding type is selected, the following rule apply:
+* - RTE_CRYPTO_RSA_PADDING_NONE:
+* This field is ignored by the PMD
+*
+* - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
+* When signing operation this field is used to determine value
+* of the DigestInfo structure, therefore specifying which algorithm
+* was used to create the message digest.
+* When doing encryption/decryption this field is ignored for this
+* padding type.
+*
+* - RTE_CRYPTO_RSA_PADDING_OAEP
+* This field shall be set with the hash algorithm used
+* in the padding scheme
+*
+* - RTE_CRYPTO_RSA_PADDING_PSS
+* This field shall be set with the hash algorithm used
+* in the padding scheme (and to create the input message digest)
*/
enum rte_crypto_auth_algorithm mgf1md;
--
2.13.6
[PATCH v2 11/14] cryptodev: move RSA padding into separate struct
- move RSA padding into separate struct.
More padding members should be added into padding,
therefore having separate struct for padding parameters will
make this more readable.
Signed-off-by: Arek Kusztal
---
app/test/test_cryptodev_asym.c | 10 ++--
drivers/common/cpt/cpt_ucode_asym.h | 4 +-
drivers/crypto/cnxk/cnxk_ae.h | 8 +--
drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
drivers/crypto/openssl/rte_openssl_pmd.c| 2 +-
drivers/crypto/qat/qat_asym.c | 12 ++---
lib/cryptodev/rte_crypto_asym.h | 76 -
7 files changed, 61 insertions(+), 55 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index a151051165..072dbb30f4 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -94,7 +94,7 @@ queue_ops_rsa_sign_verify(void *sess)
asym_op->rsa.message.length = rsaplaintext.len;
asym_op->rsa.sign.length = 0;
asym_op->rsa.sign.data = output_buf;
- asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+ asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
debug_hexdump(stdout, "message", asym_op->rsa.message.data,
asym_op->rsa.message.length);
@@ -126,7 +126,7 @@ queue_ops_rsa_sign_verify(void *sess)
/* Verify sign */
asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
- asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+ asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
/* Process crypto operation */
if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -185,7 +185,7 @@ queue_ops_rsa_enc_dec(void *sess)
asym_op->rsa.cipher.data = cipher_buf;
asym_op->rsa.cipher.length = 0;
asym_op->rsa.message.length = rsaplaintext.len;
- asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+ asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
debug_hexdump(stdout, "message", asym_op->rsa.message.data,
asym_op->rsa.message.length);
@@ -217,7 +217,7 @@ queue_ops_rsa_enc_dec(void *sess)
asym_op = result_op->asym;
asym_op->rsa.message.length = 0;
asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_DECRYPT;
- asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+ asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
/* Process crypto operation */
if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -413,7 +413,7 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym
*ts_params,
}
xform_tc.rsa.key_type = key_type;
- op->asym->rsa.pad = data_tc->rsa_data.padding;
+ op->asym->rsa.padding.type = data_tc->rsa_data.padding;
if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
asym_op->rsa.message.data = data_tc->rsa_data.pt.data;
diff --git a/drivers/common/cpt/cpt_ucode_asym.h
b/drivers/common/cpt/cpt_ucode_asym.h
index f5d91f2583..1105a0c125 100644
--- a/drivers/common/cpt/cpt_ucode_asym.h
+++ b/drivers/common/cpt/cpt_ucode_asym.h
@@ -327,7 +327,7 @@ cpt_rsa_prep(struct asym_op_params *rsa_params,
/* Result buffer */
rlen = mod_len;
- if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+ if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
/* Use mod_exp operation for no_padding type */
vq_cmd_w0.s.opcode.minor = CPT_MINOR_OP_MODEX;
vq_cmd_w0.s.param2 = exp_len;
@@ -412,7 +412,7 @@ cpt_rsa_crt_prep(struct asym_op_params *rsa_params,
/* Result buffer */
rlen = mod_len;
- if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+ if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
/*Use mod_exp operation for no_padding type */
vq_cmd_w0.s.opcode.minor = CPT_MINOR_OP_MODEX_CRT;
} else {
diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h
index 10854c79c8..0562f72270 100644
--- a/drivers/crypto/cnxk/cnxk_ae.h
+++ b/drivers/crypto/cnxk/cnxk_ae.h
@@ -288,7 +288,7 @@ cnxk_ae_rsa_prep(struct rte_crypto_op *op, struct
roc_ae_buf_ptr *meta_buf,
dptr += in_size;
dlen = total_key_len + in_size;
- if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+ if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
/* Use mod_exp operation for no_padding type */
w4.s.opcode_minor = ROC_AE_MINOR_OP_MODEX;
w4.s.param2 = exp_len;
@@ -347,7 +347,7 @@ cnxk_ae_rsa_crt_prep(struct rte_crypto_op *op, struct
roc_ae_buf_ptr *meta_buf,
dptr += in_size;
dlen = total_key_len + in_size;
- if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+ if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
/*Use mod_exp operation for no_paddi
[PATCH v2 12/14] cryptodev: clarify rsa verify with none padding
- Clarified where should output be stored of signature
decryption with padding none.
PMD is not able to know what padding algorithm was used,
therefore decrypted signature should be returned to the user.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index ee0988d3cf..9f7fba3758 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -372,8 +372,6 @@ struct rte_crypto_rsa_op_param {
* (i.e. must be at least RSA key size). The message.length
* field should be 0 and will be overwritten by the PMD
* with the decrypted length.
-*
-* All data is in Octet-string network byte order format.
*/
rte_crypto_param cipher;
@@ -388,7 +386,8 @@ struct rte_crypto_rsa_op_param {
* at least RSA key size). The cipher.length field should
* be 0 and will be overwritten by the PMD with the encrypted length.
*
-* All data is in Octet-string network byte order format.
+* When RTE_CRYPTO_RSA_PADDING_NONE and RTE_CRYPTO_ASYM_OP_VERIFY
+* selected, this is an output of decrypted signature.
*/
rte_crypto_param sign;
@@ -402,8 +401,6 @@ struct rte_crypto_rsa_op_param {
* with enough memory to hold signature output (i.e. must be
* at least RSA key size). The sign.length field should
* be 0 and will be overwritten by the PMD with the signature length.
-*
-* All data is in Octet-string network byte order format.
*/
struct rte_crypto_rsa_padding padding;
--
2.13.6
[PATCH v2 13/14] cryptodev: add salt length and optional label
- Added salt length and optional label.
Common parameters to PSS and OAEP padding for RSA.
- Fixed hash API in RSA padding.
Now it is specified how hash should be used with
particular RSA padding modes.
Signed-off-by: Arek Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 9f7fba3758..d90a7a1957 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -217,7 +217,7 @@ struct rte_crypto_rsa_priv_key_qt {
struct rte_crypto_rsa_padding {
enum rte_crypto_rsa_padding_type type;
/**< RSA padding scheme to be used for transform */
- enum rte_crypto_auth_algorithm md;
+ enum rte_crypto_auth_algorithm hash;
/**<
* RSA padding hash function
*
@@ -240,7 +240,7 @@ struct rte_crypto_rsa_padding {
* This field shall be set with the hash algorithm used
* in the padding scheme (and to create the input message digest)
*/
- enum rte_crypto_auth_algorithm mgf1md;
+ enum rte_crypto_auth_algorithm mgf1hash;
/**<
* Hash algorithm to be used for mask generation if
* padding scheme is either OAEP or PSS. If padding
@@ -248,6 +248,21 @@ struct rte_crypto_rsa_padding {
* for mask generation. Valid hash algorithms are:
* MD5, SHA1, SHA224, SHA256, SHA384, SHA512
*/
+ uint16_t pss_saltlen;
+ /**<
+* RSA PSS padding salt length
+*
+* Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is selected,
+* otherwise ignored.
+*/
+ rte_crypto_param oaep_label;
+ /**<
+* RSA OAEP padding optional label
+*
+* Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is selected,
+* otherwise ignored. If label.data == NULL, a default
+* label (empty string) is used.
+*/
};
/**
--
2.13.6
[PATCH v2 14/14] cryptodev: add asym algorithms capabilities
- Added asymmetric crypto algorithm specific capability struct.
Included fields like random number capability, padding flags etc.
Signed-off-by: Arek Kusztal
---
app/test-crypto-perf/main.c | 12 +-
app/test-eventdev/test_perf_common.c | 2 +-
app/test/test_cryptodev_asym.c | 210 +--
app/test/test_event_crypto_adapter.c | 16 +-
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 128 +++-
drivers/crypto/qat/dev/qat_asym_pmd_gen1.c | 68 +++--
lib/cryptodev/rte_crypto_asym.h | 48 ++
lib/cryptodev/rte_cryptodev.c| 80 +-
lib/cryptodev/rte_cryptodev.h| 75 +-
lib/cryptodev/version.map| 4 +
10 files changed, 495 insertions(+), 148 deletions(-)
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 17e30a8e74..f8a4c9cdcf 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -364,8 +364,8 @@ cperf_verify_devices_capabilities(struct cperf_options
*opts,
struct rte_cryptodev_sym_capability_idx cap_idx;
const struct rte_cryptodev_symmetric_capability *capability;
struct rte_cryptodev_asym_capability_idx asym_cap_idx;
- const struct rte_cryptodev_asymmetric_xform_capability *asym_capability;
-
+ const struct rte_cryptodev_asymmetric_capability *asym_capability;
+ struct rte_crypto_mod_capability mod_capa = {0};
uint8_t i, cdev_id;
int ret;
@@ -381,11 +381,11 @@ cperf_verify_devices_capabilities(struct cperf_options
*opts,
if (asym_capability == NULL)
return -1;
- ret = rte_cryptodev_asym_xform_capability_check_modlen(
- asym_capability, opts->modex_data->modulus.len);
- if (ret != 0)
+ mod_capa.max_mod_size = opts->modex_data->modulus.len;
+ ret = rte_cryptodev_capa_check_mod(asym_capability,
+ mod_capa);
+ if (ret == 0)
return ret;
-
}
if (opts->op_type == CPERF_AUTH_ONLY ||
diff --git a/app/test-eventdev/test_perf_common.c
b/app/test-eventdev/test_perf_common.c
index b41785492e..ac8e6410ab 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -846,7 +846,7 @@ cryptodev_sym_sess_create(struct prod_data *p, struct
test_perf *t)
static void *
cryptodev_asym_sess_create(struct prod_data *p, struct test_perf *t)
{
- const struct rte_cryptodev_asymmetric_xform_capability *capability;
+ const struct rte_cryptodev_asymmetric_capability *capability;
struct rte_cryptodev_asym_capability_idx cap_idx;
struct rte_crypto_asym_xform xform;
void *sess;
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 072dbb30f4..c531265642 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -311,10 +311,11 @@ test_cryptodev_asym_op(struct
crypto_testsuite_params_asym *ts_params,
struct rte_crypto_asym_xform xform_tc;
void *sess = NULL;
struct rte_cryptodev_asym_capability_idx cap_idx;
- const struct rte_cryptodev_asymmetric_xform_capability *capability;
+ const struct rte_cryptodev_asymmetric_capability *capability;
uint8_t dev_id = ts_params->valid_devs[0];
uint8_t input[TEST_DATA_SIZE] = {0};
uint8_t *result = NULL;
+ struct rte_crypto_mod_capability mod_capa = {0};
int ret, status = TEST_SUCCESS;
@@ -358,8 +359,10 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym
*ts_params,
asym_op->modex.base.length = data_tc->modex.base.len;
asym_op->modex.result.data = result;
asym_op->modex.result.length = data_tc->modex.result_len;
- if (rte_cryptodev_asym_xform_capability_check_modlen(capability,
- xform_tc.modex.modulus.length)) {
+
+ mod_capa.max_mod_size = xform_tc.modex.modulus.length;
+ if (!rte_cryptodev_capa_check_mod(capability,
+ mod_capa)) {
snprintf(test_msg, ASYM_TEST_MSG_LEN,
"line %u "
"FAILED: %s", __LINE__,
@@ -378,8 +381,10 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym
*ts_params,
asym_op->modinv.base.length = data_tc->modinv.base.len;
asym_op->modinv.result.data = result;
asym_op->modinv.result.length = data_tc->modinv.result_len;
- if (rte_cryptodev_asym_xform_capability_check_modlen(capability,
- xform_tc.modinv.modulus.length)) {
+
+ mod_capa.max_mod_size
[v5,11/11] examples/fips_validation: add parsing for aes_cbc
Added function to parse algorithm for AES_CBC test.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation.c| 8 +-
examples/fips_validation/fips_validation.h| 4 +
.../fips_validation/fips_validation_aes.c | 223 ++
examples/fips_validation/main.c | 76 --
4 files changed, 284 insertions(+), 27 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index ab4c0d0eca..8cec172a5f 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -120,7 +120,7 @@ fips_test_parse_header(void)
for (i = 0; i < info.nb_vec_lines; i++) {
if (!algo_parsed) {
- if (strstr(info.vec[i], "AESVS")) {
+ if (strstr(info.vec[i], "AES")) {
algo_parsed = 1;
info.algo = FIPS_TEST_ALGO_AES;
ret = parse_test_aes_init();
@@ -458,10 +458,12 @@ fips_test_parse_one_json_vector_set(void)
/* Vector sets contain the algorithm type, and nothing else we need. */
if (strstr(algo_str, "AES-GCM"))
info.algo = FIPS_TEST_ALGO_AES_GCM;
- if (strstr(algo_str, "HMAC"))
+ else if (strstr(algo_str, "HMAC"))
info.algo = FIPS_TEST_ALGO_HMAC;
- if (strstr(algo_str, "CMAC"))
+ else if (strstr(algo_str, "CMAC"))
info.algo = FIPS_TEST_ALGO_AES_CMAC;
+ else if (strstr(algo_str, "AES-CBC"))
+ info.algo = FIPS_TEST_ALGO_AES;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 88cbb0303e..6385ec4d8d 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -103,6 +103,7 @@ enum fips_aesavs_test_types {
AESAVS_TYPE_VARTXT,
AESAVS_TYPE_MMT,
AESAVS_TYPE_MCT,
+ AESAVS_TYPE_AFT,
};
enum fips_tdes_test_types {
@@ -262,6 +263,9 @@ parse_test_hmac_json_algorithm(void);
int
parse_test_cmac_json_init(void);
+
+int
+parse_test_aes_json_init(void);
#endif /* RTE_HAS_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_aes.c
b/examples/fips_validation/fips_validation_aes.c
index b3c5e31f32..0b7b9c0849 100644
--- a/examples/fips_validation/fips_validation_aes.c
+++ b/examples/fips_validation/fips_validation_aes.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include "fips_validation.h"
@@ -25,6 +26,19 @@
#define OP_ENC_STR "ENCRYPT"
#define OP_DEC_STR "DECRYPT"
+#define ALGO_JSON_STR "algorithm"
+#define TESTTYPE_JSON_STR "testType"
+#define DIR_JSON_STR "direction"
+#define KEYLEN_JSON_STR"keyLen"
+
+#define KEY_JSON_STR "key"
+#define IV_JSON_STR"iv"
+#define PT_JSON_STR"pt"
+#define CT_JSON_STR"ct"
+
+#define OP_ENC_JSON_STR"encrypt"
+#define OP_DEC_JSON_STR"decrypt"
+
struct {
uint32_t type;
const char *desc;
@@ -37,6 +51,7 @@ struct {
{TDES_VARIABLE_TEXT, "KAT"},
{AESAVS_TYPE_MMT, "MMT"},
{AESAVS_TYPE_MCT, "MCT"},
+ {AESAVS_TYPE_AFT, "AFT"},
};
struct aes_test_algo {
@@ -92,6 +107,214 @@ struct fips_test_callback aes_writeback_callbacks[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef RTE_HAS_JANSSON
+struct fips_test_callback aes_dec_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {IV_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {CT_JSON_STR, parse_uint8_hex_str, &vec.ct},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback aes_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_read_uint32_bit_val,
&vec.cipher_auth.key},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback aes_enc_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {IV_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {PT_JSON_STR, parse_uint8_hex_str, &vec.pt},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+static int
+parse_test_aes_json_writeback(struct fips_val *val)
+{
+ struct fips_val tmp_val;
+ json_t *tcId;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+
+ json_info.json_write_case = json_object();
+ json_object_set(json_info.json_write_case, "tcId", tcId);
+
+ if (info.op == FIPS_TEST_ENC_AUTH_GEN) {
+ json_t *ct;
+
+ tmp_val.val = val->val;
+ tmp_val.len = vec.pt.len;
+
+ writeback_hex_str("", info.one_line_text, &tmp_val);
+ ct = json_string(info.
Additional reviewers
Hello, I recently wrapped up the conversion from makefiles to meson on another project and while everything seems functional, if there is anyone that has experience with meson/time/interest, I would appreciate some more eyes on this change. For the change, most things were modeled off of how DPDK structured their meson.build files. https://gerrit.fd.io/r/c/tldk/+/36197/1 Many thanks and cheers, Ben
[PATCH v3 0/3] introduce random floating point function
Introduce a new random number function to get a floating point value. Then use it to fix PIE scheduler. v3 - rename to rte_drand() and other review feedback - fix warnings with some compilers in test code Stephen Hemminger (3): random: add rte_drand() funciton rte_pie: remove unnecessary floating point rte_pie: fix incorrect floating point math app/test/test_rand_perf.c | 7 +++ doc/guides/rel_notes/release_22_07.rst | 5 + lib/eal/common/rte_random.c| 24 lib/eal/include/rte_random.h | 18 ++ lib/eal/version.map| 1 + lib/sched/rte_pie.h| 7 ++- 6 files changed, 57 insertions(+), 5 deletions(-) -- 2.35.1
[PATCH v3 1/3] random: add rte_drand() funciton
The PIE code and other applications can benefit from having a
fast way to get a random floating point value. This new function
is equivalent to drand() in the standard library.
Signed-off-by: Stephen Hemminger
---
app/test/test_rand_perf.c | 7 +++
doc/guides/rel_notes/release_22_07.rst | 5 +
lib/eal/common/rte_random.c| 24
lib/eal/include/rte_random.h | 18 ++
lib/eal/version.map| 1 +
5 files changed, 55 insertions(+)
diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
index fe797ebfa1ca..26fb1d9a586e 100644
--- a/app/test/test_rand_perf.c
+++ b/app/test/test_rand_perf.c
@@ -20,6 +20,7 @@ static volatile uint64_t vsum;
enum rand_type {
rand_type_64,
+ rand_type_float,
rand_type_bounded_best_case,
rand_type_bounded_worst_case
};
@@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
switch (rand_type) {
case rand_type_64:
return "Full 64-bit [rte_rand()]";
+ case rand_type_float:
+ return "Floating point [rte_drand()]";
case rand_type_bounded_best_case:
return "Bounded average best-case [rte_rand_max()]";
case rand_type_bounded_worst_case:
@@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
case rand_type_64:
sum += rte_rand();
break;
+ case rand_type_float:
+ sum += 1000. * rte_drand();
+ break;
case rand_type_bounded_best_case:
sum += rte_rand_max(BEST_CASE_BOUND);
break;
@@ -83,6 +89,7 @@ test_rand_perf(void)
printf("Pseudo-random number generation latencies:\n");
test_rand_perf_type(rand_type_64);
+ test_rand_perf_type(rand_type_float);
test_rand_perf_type(rand_type_bounded_best_case);
test_rand_perf_type(rand_type_bounded_worst_case);
diff --git a/doc/guides/rel_notes/release_22_07.rst
b/doc/guides/rel_notes/release_22_07.rst
index e49cacecefd4..128d4fca85b3 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -104,6 +104,11 @@ New Features
* ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
* ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
+* ** Added function get random floating point number.**
+
+ Added the function ``rte_drand()`` to provide a pseudo-random
+ floating point number.
+
Removed Items
-
diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
index 4535cc980cec..a30bb104015b 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -6,6 +6,7 @@
#include
#endif
#include
+#include
#include
#include
@@ -173,6 +174,29 @@ rte_rand_max(uint64_t upper_bound)
return res;
}
+double
+rte_drand(void)
+{
+ struct rte_rand_state *state = __rte_rand_get_state();
+ union ieee754_double u = {
+ .ieee = {
+ .negative = 0,
+ .exponent = IEEE754_DOUBLE_BIAS,
+ },
+ };
+ uint64_t val;
+
+ /* Take 64 bit random value and put it into the mantissa
+* This uses direct access to IEEE format to avoid doing
+* any direct floating point math here.
+*/
+ val = __rte_rand_lfsr258(state);
+ u.ieee.mantissa0 = val >> 32;
+ u.ieee.mantissa1 = val;
+
+ return u.d - 1.0;
+}
+
static uint64_t
__rte_random_initial_seed(void)
{
diff --git a/lib/eal/include/rte_random.h b/lib/eal/include/rte_random.h
index 29f5f1325a30..f6541c2b0f08 100644
--- a/lib/eal/include/rte_random.h
+++ b/lib/eal/include/rte_random.h
@@ -65,6 +65,24 @@ rte_rand(void);
uint64_t
rte_rand_max(uint64_t upper_bound);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Generates a pseudo-random floating point number.
+ *
+ * This function returns a nonnegative double-precision floating random
+ * number uniformly distributed over the interval [0.0, 1.0).
+ *
+ * The generator is not cryptographically secure.
+ * If called from lcore threads, this function is thread-safe.
+ *
+ * @return
+ * A pseudo-random value between 0 and 1.0.
+ */
+__rte_experimental
+double rte_drand(void);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/eal/version.map b/lib/eal/version.map
index d49e30bd042f..cfbade9a33e9 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -422,6 +422,7 @@ EXPERIMENTAL {
rte_intr_type_set;
# added in 22.07
+ rte_drand;
rte_thread_get_affinity_by_id;
rte_thread_self;
rte_thread_set_affinity_by_id;
--
2.35.1
[PATCH v3 2/3] rte_pie: remove unnecessary floating point
The qdelay variable is derived from and compared to 64 bit
value so it doesn't have to be floating point.
Fixes: 44c730b0e379 ("sched: add PIE based congestion management")
Cc: wojciechx.liguzin...@intel.com
Signed-off-by: Stephen Hemminger
---
lib/sched/rte_pie.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/sched/rte_pie.h b/lib/sched/rte_pie.h
index 02a987f54ad1..3e2c1ef46721 100644
--- a/lib/sched/rte_pie.h
+++ b/lib/sched/rte_pie.h
@@ -218,7 +218,7 @@ _rte_pie_drop(const struct rte_pie_config *pie_cfg,
struct rte_pie *pie)
{
uint64_t rand_value;
- double qdelay = pie_cfg->qdelay_ref * 0.5;
+ uint64_t qdelay = pie_cfg->qdelay_ref / 2;
/* PIE is active but the queue is not congested: return 0 */
if (((pie->qdelay_old < qdelay) && (pie->drop_prob < 0.2)) ||
--
2.35.1
[PATCH v3 3/3] rte_pie: fix incorrect floating point math
The function rte_pie_drop was attempting to do a random probability
drop, but because of incorrect usage of fixed point divide
it would always return 1.
Change to use new rte_drand() instead.
Fixes: 44c730b0e379 ("sched: add PIE based congestion management")
Cc: wojciechx.liguzin...@intel.com
Signed-off-by: Stephen Hemminger
---
lib/sched/rte_pie.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/sched/rte_pie.h b/lib/sched/rte_pie.h
index 3e2c1ef46721..528f2ea878e8 100644
--- a/lib/sched/rte_pie.h
+++ b/lib/sched/rte_pie.h
@@ -217,7 +217,6 @@ __rte_experimental
_rte_pie_drop(const struct rte_pie_config *pie_cfg,
struct rte_pie *pie)
{
- uint64_t rand_value;
uint64_t qdelay = pie_cfg->qdelay_ref / 2;
/* PIE is active but the queue is not congested: return 0 */
@@ -240,9 +239,7 @@ _rte_pie_drop(const struct rte_pie_config *pie_cfg,
if (pie->accu_prob >= 8.5)
return 1;
- rand_value = rte_rand()/RTE_RAND_MAX;
-
- if ((double)rand_value < pie->drop_prob) {
+ if (rte_drand() < pie->drop_prob) {
pie->accu_prob = 0;
return 1;
}
--
2.35.1
Re: [PATCH v6 6/9] net/vmxnet3: add version 6 support
Hi Andrew, >> Extended interrupt structures, required implementation for additional number >> of queues It is about Vmxnet3_IntrConfExt. Vmxnet3_IntrConfExt is a control data structure shared with ESX. ESX introduced it for this version to increase the number of queues that can be used. Vmxnet3_IntrConf was used for older hardware versions Thanks, Pankaj From: Andrew Rybchenko Date: Wednesday, May 25, 2022 at 1:46 AM To: Pankaj Gupta , Jochen Behrens Cc: dev@dpdk.org Subject: Re: [PATCH v6 6/9] net/vmxnet3: add version 6 support ⚠ External Email Hi, Pankaj, On 5/25/22 03:40, Pankaj Gupta wrote: > VMXNET3 version 6 supports some new features, including but not limited to: > - Increased max MTU up to 9190 > - Increased max number of queues, both for Rx and Tx > - Removes power-of-two limitations > - Extended interrupt structures, required implementation for > additional number of queues > > Tested, using testpmd, for different hardware versions on ESXi 7.0 > Update 2. > > Signed-off-by: Pankaj Gupta > Reviewed-by: Jochen Behrens > --- > doc/guides/rel_notes/release_21_08.rst | 8 + > drivers/net/vmxnet3/base/vmxnet3_defs.h | 73 ++-- > drivers/net/vmxnet3/vmxnet3_ethdev.c| 220 +--- > drivers/net/vmxnet3/vmxnet3_ethdev.h| 10 +- > drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +- > 5 files changed, 234 insertions(+), 79 deletions(-) > > diff --git a/doc/guides/rel_notes/release_21_08.rst > b/doc/guides/rel_notes/release_21_08.rst > index 4027bd4390..810da2cc1f 100644 > --- a/doc/guides/rel_notes/release_21_08.rst > +++ b/doc/guides/rel_notes/release_21_08.rst > @@ -133,6 +133,14 @@ New Features > > * **Added RETA query and RETA update support for vmxnet3.** > > +* **Added vmxnet3 version 6 supports with some new features.** > + > + * Increased max MTU up to 9190 > + * Increased max number of queues, both for Rx and Tx > + * Removes power-of-two limitations > + * Extended interrupt structures, required implementation for additional > number > +of queues > + I've realized that I don't understand the last bullet. Could you clarify it, please, and I'll update it on applying. Also, JFYI, you should update release notes for 22.07 release, not old release notes for 21.08. Don't worry about it now - I'll move and rephrase it on applying. Thanks, Andrew. ⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
[v6, 00/11] Add JSON vector set support to fips validation
Adds a very basic introduction to JSON vector sets in the fips validation example application. This patch set will only introduce the AES-GCM test using a JSON request file because the other algorithms need more information than what is given in the new JSON format. v6: * CI centos platform fix. v5: * AES_CBC support appended in series. Brandon Lo (8): examples/fips_validation: add jansson dependency examples/fips_validation: add json info to header examples/fips_validation: add json parsing examples/fips_validation: allow json file as input examples/fips_validation: add json to gcm test examples/fips_validation: add json to hmac examples/fips_validation: implement json cmac test examples/fips_validation: add parsing for cmac Gowrishankar Muthukrishnan (3): examples/fips_validation: cleanup bypass tests in response file examples/fips_validation: reset IV generation in every test group examples/fips_validation: add parsing for aes_cbc examples/fips_validation/fips_validation.c| 117 ++- examples/fips_validation/fips_validation.h| 64 +++- .../fips_validation/fips_validation_aes.c | 223 .../fips_validation/fips_validation_cmac.c| 80 + .../fips_validation/fips_validation_gcm.c | 152 +++- .../fips_validation/fips_validation_hmac.c| 93 + examples/fips_validation/main.c | 326 +++--- examples/fips_validation/meson.build | 4 + 8 files changed, 998 insertions(+), 61 deletions(-) -- 2.25.1
[v6, 01/11] examples/fips_validation: add jansson dependency
From: Brandon Lo
Added a check for RTE_HAS_JANSSON into the meson
configuration file for JSON support.
Signed-off-by: Brandon Lo
---
examples/fips_validation/meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/examples/fips_validation/meson.build
b/examples/fips_validation/meson.build
index 7eef456318..8cd63066b5 100644
--- a/examples/fips_validation/meson.build
+++ b/examples/fips_validation/meson.build
@@ -21,3 +21,7 @@ sources = files(
'fips_dev_self_test.c',
'main.c',
)
+
+if dpdk_conf.has('RTE_HAS_JANSSON')
+ext_deps += jansson_dep
+endif
--
2.25.1
[v6, 02/11] examples/fips_validation: add json info to header
From: Brandon Lo
Added json-specific functions and other information needed to
test the new FIPS test vectors.
Signed-off-by: Brandon Lo
Signed-off-by: Gowrishankar Muthukrishnan
---
v5:
* fix typo in macro name for prefixes.
v2:
* fix type of prefix to suffix
---
examples/fips_validation/fips_validation.c | 6 +--
examples/fips_validation/fips_validation.h | 48 --
2 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 94253eaee8..38c99b291c 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -270,11 +270,11 @@ parse_file_type(const char *path)
{
const char *tmp = path + strlen(path) - 3;
- if (strstr(tmp, REQ_FILE_PERFIX))
+ if (strstr(tmp, REQ_FILE_PREFIX))
info.file_type = FIPS_TYPE_REQ;
- else if (strstr(tmp, RSP_FILE_PERFIX))
+ else if (strstr(tmp, RSP_FILE_PREFIX))
info.file_type = FIPS_TYPE_RSP;
- else if (strstr(path, FAX_FILE_PERFIX))
+ else if (strstr(path, FAX_FILE_PREFIX))
info.file_type = FIPS_TYPE_FAX;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index aaadf01ba8..a1c83a9a6a 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -5,6 +5,10 @@
#ifndef _FIPS_VALIDATION_H_
#define _FIPS_VALIDATION_H_
+#ifdef RTE_HAS_JANSSON
+#include
+#endif /* RTE_HAS_JANSSON */
+
#define FIPS_PARSE_ERR(fmt, args) \
RTE_LOG(ERR, USER1, "FIPS parse error" ## fmt ## "\n", ## args)
@@ -21,9 +25,12 @@
#define POSITIVE_TEST 0
#define NEGATIVE_TEST -1
-#define REQ_FILE_PERFIX"req"
-#define RSP_FILE_PERFIX"rsp"
-#define FAX_FILE_PERFIX"fax"
+#define REQ_FILE_PREFIX"req"
+#define RSP_FILE_PREFIX"rsp"
+#define FAX_FILE_PREFIX"fax"
+#define JSON_FILE_PREFIX "json"
+
+#define ACVVERSION "1.0"
enum fips_test_algorithms {
FIPS_TEST_ALGO_AES = 0,
@@ -40,7 +47,8 @@ enum fips_test_algorithms {
enum file_types {
FIPS_TYPE_REQ = 1,
FIPS_TYPE_FAX,
- FIPS_TYPE_RSP
+ FIPS_TYPE_RSP,
+ FIPS_TYPE_JSON,
};
enum fips_test_op {
@@ -161,6 +169,23 @@ struct gcm_interim_data {
uint8_t gen_iv;
};
+#ifdef RTE_HAS_JANSSON
+struct fips_test_json_info {
+ /* Information used for reading from json */
+ json_t *json_root;
+ json_t *json_vector_set;
+ json_t *json_test_group;
+ json_t *json_test_case;
+ /* Location of json write output */
+ json_t *json_write_root;
+ json_t *json_write_group;
+ json_t *json_write_set;
+ json_t *json_write_case;
+ /* Other info */
+ uint8_t is_sample;
+};
+#endif /* RTE_HAS_JANSSON */
+
struct fips_test_interim_info {
FILE *fp_rd;
FILE *fp_wr;
@@ -196,6 +221,10 @@ struct fips_test_interim_info {
extern struct fips_test_vector vec;
extern struct fips_test_interim_info info;
+#ifdef RTE_HAS_JANSSON
+extern struct fips_test_json_info json_info;
+#endif /* RTE_HAS_JANSSON */
+
int
fips_test_init(const char *req_file_path, const char *rsp_file_path,
const char *device_name);
@@ -212,6 +241,17 @@ fips_test_parse_one_case(void);
void
fips_test_write_one_case(void);
+#ifdef RTE_HAS_JANSSON
+int
+fips_test_parse_one_json_vector_set(void);
+
+int
+fips_test_parse_one_json_group(void);
+
+int
+fips_test_parse_one_json_case(void);
+#endif /* RTE_HAS_JANSSON */
+
int
parse_test_aes_init(void);
--
2.25.1
[v6, 03/11] examples/fips_validation: add json parsing
From: Brandon Lo
Added functions to parse the required information from a vector set
given in the new json format.
Signed-off-by: Brandon Lo
---
v3:
* fix checkpatch warnings
v2:
* fix for loop initialization
---
examples/fips_validation/fips_validation.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 38c99b291c..6594a15579 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -276,6 +276,8 @@ parse_file_type(const char *path)
info.file_type = FIPS_TYPE_RSP;
else if (strstr(path, FAX_FILE_PREFIX))
info.file_type = FIPS_TYPE_FAX;
+ else if (strstr(path, JSON_FILE_PREFIX))
+ info.file_type = FIPS_TYPE_JSON;
else
return -EINVAL;
@@ -311,6 +313,21 @@ fips_test_init(const char *req_file_path, const char
*rsp_file_path,
return -EINVAL;
}
+ if (info.file_type == FIPS_TYPE_JSON) {
+#ifdef RTE_HAS_JANSSON
+ json_error_t error;
+ json_info.json_root = json_loadf(info.fp_rd, 0, &error);
+ if (!json_info.json_root) {
+ RTE_LOG(ERR, USER1, "Cannot parse json file %s (line
%d, column %d)\n",
+ req_file_path, error.line, error.column);
+ return -EINVAL;
+ }
+#else /* RTE_HAS_JANSSON */
+ RTE_LOG(ERR, USER1, "No json library configured.\n");
+ return -EINVAL;
+#endif /* RTE_HAS_JANSSON */
+ }
+
info.fp_wr = fopen(rsp_file_path, "w");
if (!info.fp_wr) {
RTE_LOG(ERR, USER1, "Cannot open file %s\n", rsp_file_path);
@@ -329,6 +346,9 @@ fips_test_init(const char *req_file_path, const char
*rsp_file_path,
return -EINVAL;
}
+ if (info.file_type == FIPS_TYPE_JSON)
+ return 0;
+
if (fips_test_parse_header() < 0) {
RTE_LOG(ERR, USER1, "Failed parsing header\n");
return -1;
@@ -428,6 +448,78 @@ fips_test_write_one_case(void)
fprintf(info.fp_wr, "%s\n", info.vec[i]);
}
+#ifdef RTE_HAS_JANSSON
+int
+fips_test_parse_one_json_vector_set(void)
+{
+ json_t *algo_obj = json_object_get(json_info.json_vector_set,
"algorithm");
+ const char *algo_str = json_string_value(algo_obj);
+
+ /* Vector sets contain the algorithm type, and nothing else we need. */
+ if (strstr(algo_str, "AES-GCM"))
+ info.algo = FIPS_TEST_ALGO_AES_GCM;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+int
+fips_test_parse_one_json_group(void)
+{
+ int ret, i;
+ json_int_t val;
+ json_t *param;
+
+ if (info.interim_callbacks) {
+ char json_value[256];
+ for (i = 0; info.interim_callbacks[i].key != NULL; i++) {
+ param = json_object_get(json_info.json_test_group,
+ info.interim_callbacks[i].key);
+ val = json_integer_value(param);
+ snprintf(json_value, 255, "%"JSON_INTEGER_FORMAT, val);
+ /* First argument is blank because the key
+* is not included in the string being parsed.
+*/
+ ret = info.interim_callbacks[i].cb(
+ "", json_value,
+ info.interim_callbacks[i].val
+ );
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+int
+fips_test_parse_one_json_case(void)
+{
+ uint32_t i;
+ int ret = 0;
+ json_t *param;
+
+ for (i = 0; info.callbacks[i].key != NULL; i++) {
+ param = json_object_get(json_info.json_test_case,
info.callbacks[i].key);
+ if (param) {
+ strcpy(info.one_line_text, json_string_value(param));
+ /* First argument is blank because the key
+* is not included in the string being parsed.
+*/
+ ret = info.callbacks[i].cb(
+ "", info.one_line_text,
+ info.callbacks[i].val
+ );
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+#endif /* RTE_HAS_JANSSON */
+
static int
parser_read_uint64_hex(uint64_t *value, const char *p)
{
--
2.25.1
