From mboxrd@z Thu Jan  1 00:00:00 1970
From: Akhil Goyal <akhil.goyal@nxp.com>
Subject: Re: [PATCH 6/6] cryptodev: replace mbuf scatter gather
 flag
Date: Mon, 18 Jun 2018 11:59:38 +0530
Message-ID: <14d048b2-2787-0365-08ac-5ffef6128bec@nxp.com>
References: <20180608220234.10170-1-pablo.de.lara.guarch@intel.com>
 <20180608220234.10170-7-pablo.de.lara.guarch@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
To: Pablo de Lara <pablo.de.lara.guarch@intel.com>, declan.doherty@intel.com,
 akhil.goyal@nxp.com, ravi1.kumar@amd.com, jerin.jacob@caviumnetworks.com,
 roy.fan.zhang@intel.com, fiona.trahe@intel.com, tdu@semihalf.com,
 jianjay.zhou@huawei.com
Return-path: <dev-bounces@dpdk.org>
Received: from EUR03-DB5-obe.outbound.protection.outlook.com
 (mail-eopbgr40071.outbound.protection.outlook.com [40.107.4.71])
 by dpdk.org (Postfix) with ESMTP id 799B15F0D
 for <dev@dpdk.org>; Mon, 18 Jun 2018 08:29:59 +0200 (CEST)
In-Reply-To: <20180608220234.10170-7-pablo.de.lara.guarch@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Pablo,
On 6/9/2018 3:32 AM, Pablo de Lara wrote:
> The current mbuf scatter gatter feature flag is
> too ambiguous, as it is not clear if input and/or output
> buffers can be scatter gather mbufs or not.
>
> Therefore, two new flags will replace this flag:
> RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER_IN and
> RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER_OUT.
>
There may be a case, SG supported in input buffer and we use in-place 
processing and driver may support that but may not support SG for out 
buffers in case of OOP. How can we handle this type of case?

> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst        |  2 -
>  doc/guides/rel_notes/release_18_08.rst      |  4 ++
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd.c    |  2 +-
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |  2 +-
>  drivers/crypto/dpaa_sec/dpaa_sec.c          |  3 +-
>  drivers/crypto/null/null_crypto_pmd.c       |  3 +-
>  drivers/crypto/openssl/rte_openssl_pmd.c    |  2 +-
>  drivers/crypto/qat/rte_qat_cryptodev.c      |  3 +-
>  lib/librte_cryptodev/rte_cryptodev.c        |  6 ++-
>  lib/librte_cryptodev/rte_cryptodev.h        | 12 +++---
>  test/test/test_cryptodev.c                  | 41 ++++++++++++++-------
>  test/test/test_cryptodev_blockcipher.c      | 11 ++++--
>  12 files changed, 59 insertions(+), 32 deletions(-)
>