Hi Akhil/Fan
Patchset verified for QAT and AESNI_MB sessions, with particular focus on
Security Cipher-CRC
For the series,
Tested-by: David Coyle
Tested-by: Kevin O'Sullivan
Regards,
David
> -Original Message-
> From: Akhil Goyal
> Sent: Wednesday, September 21, 2022 4:11 PM
> To: A
Hi Anoob,
Thank you for the comments.
See inline below for replies.
Regards,
David
> -Original Message-
> From: Anoob Joseph
> Sent: Monday, September 18, 2023 12:03 PM
> To: Coyle, David
> Cc: Ji, Kai ; O'Sullivan, Kevin ;
> dev@dpdk.org; Jerin Jacob Kolla
Hi Anoob,
Thank you for that feedback - I was on extended leave so only just getting back
to it now.
See replies below.
Regards,
David
> -Original Message-
> From: Anoob Joseph
> Sent: Friday, August 11, 2023 12:09 PM
> To: Coyle, David ; dev@dpdk.org
> Cc: Ji, Kai ; O&
Hi Morten
> -Original Message-
> From: Morten Brørup
>
> > From: David Coyle [mailto:david.co...@intel.com]
> > Sent: Wednesday, 3 May 2023 13.39
> >
> > This is NOT for upstreaming. This is being submitted to allow early
> > comparison testing with the preferred solution, which will add
Hi Morten
> -Original Message-
> From: Morten Brørup
>
> Power saving is important for the environment (to save the planet and all
> that), so everyone should contribute, if they have a good solution. So even if
> our algorithm had a significant degree of innovation, we would probably
Hi Rebecca, see below
> -Original Message-
> From: Troy, Rebecca
>
> In the current implementation, the docsis test cases are running and being
> reported as one test, despite the fact that multiple test cases are hidden
> inside i.e. "test_DOCSIS_PROTO_all" runs
> 52 test cases. Each d
> -Original Message-
> From: Troy, Rebecca
> Sent: Friday, October 29, 2021 10:04 AM
> To: dev@dpdk.org
> Cc: Power, Ciara ; Zhang, Roy Fan
> ; Coyle, David ; Troy,
> Rebecca ; Akhil Goyal ;
> Doherty, Declan
> Subject: [PATCH v2] test/crypto: refactor
> -Original Message-
> From: David Marchand
> Sent: Tuesday, June 23, 2020 3:52 PM
>
> > A number of approaches to combine DOCSIS Crypto and CRC functions
> have
> > been discussed in the DPDK community to date, namely:
> > 1) adding a new rte_accelerator API, to provide a generic inter
> -Original Message-
> From: David Marchand
> Sent: Tuesday, June 23, 2020 4:39 PM
> > > I guess https://patchwork.dpdk.org/project/dpdk/list/?series=9304
> > > can be marked Superseded then.
> > > Thanks.
> >
> > [DC] Yes it can - I have tried to set it to Superseded but don't have
> > pe
> -Original Message-
> From: David Marchand
> Sent: Tuesday, June 23, 2020 5:22 PM
> To: Coyle, David
> > > > > I guess
> > > > > https://patchwork.dpdk.org/project/dpdk/list/?series=9304
> > > > > can be marked Superseded then.
&
Hi Akhil
> -Original Message-
> From: Akhil Goyal
> Sent: Tuesday, June 23, 2020 7:38 PM
> > > >
> > > [DC] It's certainly an option and would work but I don't think it's
> > > a good idea to
> > be putting
> > > protocol specific structs like this in rte_cryptodev - that's what
> > > rte
Hi Akhil,
> -Original Message-
> From: Akhil Goyal
> Sent: Tuesday, June 23, 2020 7:07 PM
> >
> > +/**
> > + * DOCSIS operation parameters
> > + */
> > +struct rte_security_docsis_op {
> > + struct rte_crypto_sym_op crypto_sym;
> > + /**< Symmetric crypto operation parameters */
> > +
Hi Pablo, thank you for the comments
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, June 23, 2020 6:57 PM
>
> > +static inline void
> > +verify_docsis_sec_crc(JOB_AES_HMAC *job, uint16_t crc_len, uint8_t
> > +*status) {
> > + uint16_t crc_offset;
> > + uint8_t *c
Hi Pablo
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, June 23, 2020 7:04 PM
>
> > +static int
> > +test_docsis_proto_uplink(int i, struct docsis_test_data *d_td) {
> > + struct rte_security_op *sec_op;
> > + struct rte_security_docsis_op *doc_op;
> > + struct
Hi Pablo
> -Original Message-
> From: De Lara Guarch, Pablo
> > +/**
> > + * DOCSIS security session configuration.
> > + *
> > + * This structure contains data required to create a DOCSIS security
> session.
> > + */
> > +struct rte_security_docsis_xform {
> > + enum rte_security_docsi
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index 2d688f4d3..4b25c5e23 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -1647,7 +1914,23 @@ cryptodev_aesni_mb_create(
Hi Akhil, thank you for these comments
>
> This patch should be split and merged to relevant other patches in the series.
> rte_security related in 1/8
> Like aesni-mb related changes should go in 3/8 qat related should be part of
> 4/8 crypto-perf should be part of 7/8 And release notes should a
> diff --git a/drivers/crypto/qat/qat_sym_pmd.c
> b/drivers/crypto/qat/qat_sym_pmd.c
> index e887c880f..711d1585f 100644
> --- a/drivers/crypto/qat/qat_sym_pmd.c
> +++ b/drivers/crypto/qat/qat_sym_pmd.c
> @@ -308,7 +346,20 @@ qat_sym_dev_create(struct qat_pci_device
> *qat_pci_dev,
>
Thank you Thomas for your input.
We would like to request that the Tech-Board (CC'ed) also review the proposal
to help us reach a consensus.
If the current proposal is not acceptable, we would welcome feedback from the
board on how to rework our
proposal to something that would be acceptable.
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, April 21, 2020 6:25 PM
[PATCH v3 0/4] add AESNI-MB rawdev for multi-
> function processing
>
> 21/04/2020 18:46, Doherty, Declan:
> > On 15/04/2020 11:33 PM, Thomas Monjalon wrote:
> > > 16/04/2020 00:19, Doherty, Declan:
> >
Hi Akhil,
> -Original Message-
> From: Akhil Goyal
> Sent: Wednesday, April 22, 2020 11:51 AM
> Hi David,
> > > >>
> > > >> I don't agree rte_security addresses the problem of different
> > > >> device types supporting the same services. The problem being
> > > >> addressed here is a sin
Hi Akhil
> -Original Message-
> From: Akhil Goyal
> Sent: Wednesday, April 22, 2020 2:44 PM
>
> Hi David,
> > Hi Akhil,
> >
> > > > >
> > > I did not look at your patches completely, but looking at the ops
> > > that you have added For rawdev are pretty much same as that of a crypto
> de
Hi Kevin,
> -Original Message-
> From: Kevin Traynor
> Sent: Wednesday, April 22, 2020 3:02 PM
>
> Hi David,
>
> On 21/04/2020 18:23, Coyle, David wrote:
> > Thank you Thomas for your input.
> >
> > We would like to request that the Tech-Board (CC
Hi Fan & Akhil,
> -Original Message-
> From: Zhang, Roy Fan
> Sent: Friday, May 1, 2020 2:18 PM
>
> Hi Akhil,
>
> > -Original Message-
> > From: dev On Behalf Of Akhil Goyal
> > Sent: Wednesday, April 22, 2020 2:44 PM
> > T
Hi Ferruh, see below
> >
> > While DPDK's rte_cryptodev and rte_compressdev allow many
> > cryptographic and compression algorithms to be chained together in one
> > operation, there is no way to chain these with any error detection or
> > checksum algorithms. And there is no way to chain crypto a
rahe, Fiona
> Sent: Tuesday, April 7, 2020 7:06 PM
>
> Hi David, Ferruh,
>
> > -Original Message-
> > From: Coyle, David
> > Sent: Tuesday, April 7, 2020 12:28 PM
> > To: Yigit, Ferruh ; dev@dpdk.org
> >
> > Hi Ferruh, see below
> >
>
Hi Fiona, see below
> -Original Message-
> From: Trahe, Fiona
> Sent: Thursday, April 9, 2020 10:37 AM
>
> Hi David,
>
> Answer inline below
>
> > -Original Message-
> > From: Coyle, David
> > Sent: Thursday, April 9, 2020 10:26 AM
&g
Hi Pablo
Thank you for reviewing and the comments - see below for resolutions.
The changes will be available in v3 shortly
David
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Monday, April 6, 2020 5:09 PM
>
> Hi David,
>
> > -Original Mess
Hi Pablo
Thank you for reviewing and the comments - see below for resolutions.
The changes will be available in v3 shortly
David
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, April 7, 2020 7:51 PM
>
> Hi David,
>
> > -Original Mess
Hi Pablo,
Thank you for reviewing and the comments - see below for resolutions.
The changes will be available in v3 shortly
David
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, April 7, 2020 7:55 PM
>
> > -Original Message-----
> > From
Hi Pablo
Thank you for reviewing and the comments - see below for resolutions.
The changes will be available in v3 shortly
David
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, April 7, 2020 7:56 PM
>
> Hi David,
>
> > -Original Mess
Hi Akhil
> -Original Message-
> From: akhil.go...@nxp.com
> Sent: Thursday, September 3, 2020 9:10 PM
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index
> 70bf6fe2c..6d7da1408 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -7219,
Hi Ciara,
> From: dev On Behalf Of Ciara Power
> When choosing a vector path to take, an extra condition must be satisfied to
> ensure the max SIMD bitwidth allows for the CPU enabled path.
>
> The vector path was initially chosen in RTE_INIT, however this is no longer
> suitable as we cannot ch
Hi Pablo
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Friday, July 17, 2020 8:29 PM
> >
> > #ifdef AESNI_MB_DOCSIS_SEC_ENABLED
> > + struct rte_security_ctx *security_instance;
> > security_instance = rte_malloc("aesni_mb_sec",
> > sizeof(s
Hi Akhil,
> -Original Message-
> From: Akhil Goyal
> Sent: Saturday, July 18, 2020 10:41 PM
> > > > This patch makes some minor improvements to the security instance
> > > > setup for the QAT SYM PMD. All of this setup code is now in one
> > > > '#ifdef RTE_LIBRTE_SECURITY' block. Enablin
Hi Pablo,
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Friday, July 17, 2020 8:04 PM
> > @@ -48,6 +48,10 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
> > } else
> > buf_sz = options->test_buffer_size;
> >
> > +
Hi Jerin,
Thanks for the comments. Please see replies below.
Kind Regards,
David
> On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
> >
> > Introduction
> >
> >
> > This RFC introduces a new DPDK library, rte_accelerator.
> >
> > The main aim of this library is to provide a flexibl
Hi Jerin, see reply below
> On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
> >
> > Hi Jerin,
>
> Hi David,
>
> > Thanks for the comments. Please see replies below.
> >
> > Kind Regards,
> > David
> >
> > > On Tue, Feb 4, 202
Hi Jerin, see below
>
> On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> wrote:
>
> Hi David,
>
> > >
> > >
> > > > > > - XGS-PON MAC: Crypto-CRC-BIP
> > > > > > - Order:
> > > > > >
Having taken feedback from the community into account, we would like to propose
some changes to our approach for combining multiple packet-processing functions
into a single operation on a single device, be that an optimized software
library or a hardware accelerator.
The main feedback on the r
> >
> > Having an API that could be used by parallel hardware does make sense,
> > but the DPDK already has multiple packet processing infrastructure pieces.
> >
> > I would rather the DPDK converge on one widely used, robust and tested
> > packet method. Rather than the current "choose your poison
> >
> > /** Error Detection Algorithms */
> > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
>
> IMO, It does not make sense to add protocol specific stuff in rawdev
> symbols.
>
> IMO, It is better to have a separate library for CRC and BIP3
Hi Konstantin, see below
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, June 9, 2020 2:23 PM
>
>
> >
> > /** Status of crypto operation */
> > @@ -121,6 +123,13 @@ struct rte_crypto_op {
> > struct rte_crypto_asym_op asym[0];
> > /**< Asymmetr
Hi Konstantin,
> > >
> > > >
> > > > /** Status of crypto operation */ @@ -121,6 +123,13 @@ struct
> > > > rte_crypto_op {
> > > > struct rte_crypto_asym_op asym[0];
> > > > /**< Asymmetric operation parameters */
> > > >
> > > > +#ifdef RTE_LIBRTE_SECURITY
> > > >
Hi Konstantin,
> > > > >
> > > > > >
> > > > > > /** Status of crypto operation */ @@ -121,6 +123,13 @@ struct
> > > > > > rte_crypto_op {
> > > > > > struct rte_crypto_asym_op asym[0];
> > > > > > /**< Asymmetric operation parameters */
> > > > > >
> > > > > > +#ifdef RTE
>
> On Fri, Mar 6, 2020 at 8:25 PM Coyle, David wrote:
> >
> > > >
> > > > /** Error Detection Algorithms */
> > > > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > > > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
> > >
> The API ``rte_security_session_create`` takes only single mempool for
> session and session private data. So the application need to create mempool
> for twice the number of sessions needed and will also lead to wastage of
> memory as session private data need more memory compared to session.
> H
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Tuesday, March 30, 2021 6:30 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 1/3] net/iavf: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory from t
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Tuesday, March 30, 2021 6:30 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 2/3] net/ice: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory from th
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Tuesday, March 30, 2021 6:30 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 3/3] net/i40e: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory from t
> -Original Message-
> From: dev On Behalf Of Savinay Dharmappa
> Sent: Tuesday, March 9, 2021 4:10 PM
> To: Singh, Jasvinder ; Dumitrescu, Cristian
> ; dev@dpdk.org
> Cc: Dharmappa, Savinay
> Subject: [dpdk-dev] [PATCH v2] sched : Initialize tc ov watermark.
>
> tc ov watermark is ini
Hi Wenzhuo
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Friday, March 12, 2021 1:27 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] net/iavf: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory f
Hi Wenzhuo
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Friday, March 12, 2021 1:27 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH 2/3] net/ice: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory fr
Hi Wenzhuo
> -Original Message-
> From: dev On Behalf Of Wenzhuo Lu
> Sent: Friday, March 12, 2021 1:27 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH 3/3] net/i40e: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory f
Hi Leyi
> -Original Message-
> From: dev On Behalf Of Leyi Rong
> Sent: Wednesday, March 17, 2021 9:18 AM
> To: Zhang, Qi Z ; Lu, Wenzhuo
> ; Xing, Beilei
> Cc: dev@dpdk.org; Rong, Leyi
> Subject: [dpdk-dev] [PATCH] net/iavf: fix pkt len parsing in AVX512
>
> Fix pkt_len parsing when D
Hi Jasvinder/Ciara
> -Original Message-
> From: Singh, Jasvinder
> >
> > > From: dev On Behalf Of Ciara Power When
> > > choosing a vector path to take, an extra condition must be satisfied
> > > to ensure the max SIMD bitwidth allows for the CPU enabled path.
> > >
> > > The vector path
Hi Ciara
> -Original Message-
> From: dev On Behalf Of Ciara Power
> diff --git a/lib/librte_eal/common/eal_internal_cfg.h
> b/lib/librte_eal/common/eal_internal_cfg.h
> index 13f93388a7..367e0cc19e 100644
> --- a/lib/librte_eal/common/eal_internal_cfg.h
> +++ b/lib/librte_eal/common/e
Hi Akhil
> -Original Message-
> From: akhil.go...@nxp.com
> diff --git a/doc/guides/prog_guide/rte_security.rst
> b/doc/guides/prog_guide/rte_security.rst
> index 127da2e4f..ab535d1cd 100644
> --- a/doc/guides/prog_guide/rte_security.rst
> +++ b/doc/guides/prog_guide/rte_security.rst
>
Hi Pablo
> >
> > When destroying a security session, the AESNI-MB PMD attempted to
> > clear the private aesni_mb session object to remove any key material.
> > However, the function aesni_mb_pmd_sec_sess_destroy() cleared the
> > security session object instead of the private session object.
> >
Hi Konstantin, thanks for your review
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, October 7, 2020 3:59 PM
>
> >
> > This patch adds support for run-time selection of the optimal
> > architecture-specific CRC path, based on the supported instruction
> > set(s) o
-Original Message-
From: Van Haaren, Harry
Sent: Monday, July 30, 2018 6:34 PM
To: dev@dpdk.org
Cc: Van Haaren, Harry ; Richardson, Bruce
; sta...@dpdk.org; tho...@monjalon.net; Coyle,
David ; Xing, Beilei ; Zhang, Qi
Z
Subject: [PATCH v2] net/i40e: fix avx2 driver check for rx
61 matches
Mail list logo
