From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 3E5EC5583 for ; Fri, 24 Mar 2017 11:52:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490352774; x=1521888774; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YbpLJkQF4Qcm6dp2jeT6eFZK5kP+kRC1OYcoJisCrH8=; b=QICD3Vi2u+ysYIIiFIjsRsAnAUfvPq4/bpus6F3QvU5LqB9NQL/JOlO6 TgjYBsqFfdk5kbzrhGEckZ9zbPDicw==; Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 03:52:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,214,1486454400"; d="scan'208";a="64491070" Received: from dwdohert-mobl1.ger.corp.intel.com (HELO [163.33.228.170]) ([163.33.228.170]) by orsmga002.jf.intel.com with ESMTP; 24 Mar 2017 03:52:49 -0700 To: Fiona Trahe , dev@dpdk.org, pablo.de.lara.guarch@intel.com References: <1490290570-14651-1-git-send-email-fiona.trahe@intel.com> From: Declan Doherty Message-ID: <927ebdcb-132e-b1a6-e427-fa60cb8ac3b3@intel.com> Date: Fri, 24 Mar 2017 10:52:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1490290570-14651-1-git-send-email-fiona.trahe@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] cryptodev: add API note X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 10:52:54 -0000 On 23/03/2017 5:36 PM, Fiona Trahe wrote: > Add note to cryptodev API that chained mbufs > are not supported in DOCSISBPI mode. > > Signed-off-by: Fiona Trahe > --- ... > Hey Fiona, Is this really a limitation of DOCSISBPI mode or just the PMDs which currently support these operations. I don't see any reason why DOCSISBPI mode cipher operation precludes scatter gather operations on the source payload. If there is some fundamental reason why scatter gather operations can't be supported I think documenting this in the rte_crypto_cipher_algorithm enumeration comments make more sense than in the rte_crypto_sym_op structure, as we already specify extra requirements RTE_CRYPTO_CIPHER_AES_GCM and RTE_CRYPTO_CIPHER_AES_CCM there.