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
>
> 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 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 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
> -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
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: 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 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 1/3] net/iavf: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory from t
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 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 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 1/3] net/iavf: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory f
> -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 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
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 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 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 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,
> 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 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,
> 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
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 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:29 PM
> >
> > #ifdef AESNI_MB_DOCSIS_SEC_ENABLED
> > + struct rte_security_ctx *security_instance;
> > security_instance = rte_malloc("aesni_mb_sec",
> > sizeof(s
> 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,
>
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/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 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
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, 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 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 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
> -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.
&
> -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 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
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
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, 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 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 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 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 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
> -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:
> >
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.
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 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: 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 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
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 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
>
> 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,
> > >
> >
> > /** 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
> >
> > 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
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
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:
> > > > > >
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,
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
-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
