DPDK patches and discussions
 help / color / mirror / Atom feed
From: Hemant Agrawal <hemant.agrawal@oss.nxp.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"gakhil@marvell.com" <gakhil@marvell.com>
Cc: "anoobj@marvell.com" <anoobj@marvell.com>,
	"Nicolau, Radu" <radu.nicolau@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"matan@nvidia.com" <matan@nvidia.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
	"asomalap@amd.com" <asomalap@amd.com>,
	"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
	"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"adwivedi@marvell.com" <adwivedi@marvell.com>,
	"jianjay.zhou@huawei.com" <jianjay.zhou@huawei.com>,
	Gagandeep Singh <G.Singh@nxp.com>
Subject: Re: [dpdk-dev] [PATCH v2] doc: announce change in crypto raw data vector
Date: Fri, 6 Aug 2021 15:55:48 +0530	[thread overview]
Message-ID: <aaaa815a-6b63-c730-b443-ee074ea44d2f@oss.nxp.com> (raw)
In-Reply-To: <DM6PR11MB4491D03EC1E1590106BBF2749AF39@DM6PR11MB4491.namprd11.prod.outlook.com>

Hi Konstantin

On 8/6/2021 3:34 PM, Ananyev, Konstantin wrote:
> Hi Hemant,
>
>>> The current crypto raw data vectors need to be extended to support
>>> out of place processing. It is proposed to add additional desl_sgl
>>> to provide details for destination sgl.
>>> The same is also extended to support rte_security usecases, where
>>> we need total data length to know how much additional memory space
>>> is available in buffer other than data length so that driver/HW
>>> can write expanded size data after encryption.
>>>
>>> Signed-off-by: Gagandeep Singh <G.Singh@nxp.com>
>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>> ---
>>>    doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++
>>>    1 file changed, 12 insertions(+)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>>> index f4a4d00db2..c19a306c93 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -193,3 +193,15 @@ Deprecation Notices
>>>      reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other
>>>      information from the crypto/security operation. This field will be used to
>>>      communicate events such as soft expiry with IPsec in lookaside mode.
>>> +
>>> +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add
>>> +  ``dest_sgl`` to support out of place processing. This field will be null for
>>> +  inplace processing. This change is targeted for DPDK 21.11
> Seems ok to me, just one question:
> would layout (number of elems in SG, length of each elem)
> for sgl and dest_sgl always be identical?

No, there shall not be any such restriction. Both source and destination 
can be different buffer  with their own number of elem (if any) and 
length of each elem.

>>> +
>>> +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add
>>> +  ``tot_len`` to support total buffer length. This is required for security
>>> +  cases like IPsec and PDCP encryption offload to know how much additional
>>> +  memory space is available in buffer other than data length so that driver/HW
>>> +  can write expanded size data after encryption. This change is targeted for
>>> +  DPDK 21.11
>>> +
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>

  reply	other threads:[~2021-08-06 10:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05  8:05 [dpdk-dev] [PATCH] " Hemant Agrawal
2021-08-05 13:49 ` Zhang, Roy Fan
2021-08-05 13:52   ` Hemant Agrawal
2021-08-05 13:55 ` [dpdk-dev] [PATCH v2] " Hemant Agrawal
2021-08-05 14:04   ` [dpdk-dev] [EXT] " Akhil Goyal
2021-08-07 15:17     ` Thomas Monjalon
2021-08-06  6:35   ` [dpdk-dev] " Hemant Agrawal
2021-08-06 10:04     ` Ananyev, Konstantin
2021-08-06 10:25       ` Hemant Agrawal [this message]
2021-08-06 10:38         ` Ananyev, Konstantin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaaa815a-6b63-c730-b443-ee074ea44d2f@oss.nxp.com \
    --to=hemant.agrawal@oss.nxp.com \
    --cc=G.Singh@nxp.com \
    --cc=adwivedi@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=anoobj@marvell.com \
    --cc=asomalap@amd.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=gakhil@marvell.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=matan@nvidia.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=radu.nicolau@intel.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=ruifeng.wang@arm.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).