From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A11AA1E34 for ; Tue, 22 May 2018 12:08:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2018 03:08:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,429,1520924400"; d="scan'208";a="60701317" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 22 May 2018 03:08:08 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.150]) by IRSMSX101.ger.corp.intel.com ([169.254.1.118]) with mapi id 14.03.0319.002; Tue, 22 May 2018 11:08:07 +0100 From: "De Lara Guarch, Pablo" To: "De Lara Guarch, Pablo" , "Verma, Shally" , "Trahe, Fiona" , "dev@dpdk.org" CC: "Gupta, Ashish" , "Sahu, Sunila" Thread-Topic: [dpdk-dev] [PATCH] compressdev: clarify buffer size limitation Thread-Index: AQHT7SDt3nunmkIX8ESKnpLeOunfBqQzYHyAgAdrroCAAMMSoA== Date: Tue, 22 May 2018 10:08:05 +0000 Message-ID: References: <1526480339-13056-1-git-send-email-fiona.trahe@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDVkN2FhNDEtYjM4NC00ZDZiLThjNjgtZTY5Zjk0MzY2ZGEyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidWdSVTdHWWxaa0N6RkVkK1BseFhUTE04NlFPazcrM0dQd1dZOCtYOTkyUmU3TG5UbEw2eW9FMmMyeFlYNnhhXC8ifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] compressdev: clarify buffer size limitation 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: Tue, 22 May 2018 10:08:11 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch, Pabl= o > Sent: Monday, May 21, 2018 11:32 PM > To: Verma, Shally ; Trahe, Fiona > ; dev@dpdk.org > Cc: Gupta, Ashish ; Sahu, Sunila > > Subject: Re: [dpdk-dev] [PATCH] compressdev: clarify buffer size limitati= on >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Verma, Shally > > Sent: Thursday, May 17, 2018 7:10 AM > > To: Trahe, Fiona ; dev@dpdk.org > > Cc: De Lara Guarch, Pablo ; Gupta, > > Ashish ; Sahu, Sunila > > > > Subject: Re: [dpdk-dev] [PATCH] compressdev: clarify buffer size > > limitation > > > > > > > > >-----Original Message----- > > >From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Fiona Trahe > > >Sent: 16 May 2018 19:49 > > >To: dev@dpdk.org > > >Cc: pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com > > >Subject: [dpdk-dev] [PATCH] compressdev: clarify buffer size > > >limitation > > > > > >Signed-off-by: Fiona Trahe > > >--- > > > lib/librte_compressdev/rte_comp.h | 11 +++++++++-- > > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > > >diff --git a/lib/librte_compressdev/rte_comp.h > > b/lib/librte_compressdev/rte_comp.h > > >index 4c802195f..9826086b1 100644 > > >--- a/lib/librte_compressdev/rte_comp.h > > >+++ b/lib/librte_compressdev/rte_comp.h > > >@@ -295,12 +295,19 @@ struct rte_comp_op { > > > struct rte_mbuf *m_src; > > > /**< source mbuf > > > * The total size of the input buffer(s) can be retrieved using > > >- * rte_pktmbuf_data_len(m_src) > > >+ * rte_pktmbuf_data_len(m_src). The max data size which can fit in a > > >+ * single mbuf is limited by the uint16_t rte_mbuf.data_len to 64k-1= . > > >+ * If the input data is bigger than this it can be passed to the PMD= in > > >+ * a chain of mbufs if the PMD's capabilities indicate it supports t= his. > > > */ > > > struct rte_mbuf *m_dst; > > > /**< destination mbuf > > > * The total size of the output buffer(s) can be retrieved using > > >- * rte_pktmbuf_data_len(m_dst) > > >+ * rte_pktmbuf_data_len(m_dst). The max data size which can fit in a > > >+ * single mbuf is limited by the uint16_t rte_mbuf.data_len to 64k-1= . > > >+ * If the output data is expected to be bigger than this a chain of > > >+ * mbufs can be passed to the PMD if the PMD's capabilities indicate > > >+ * it supports this. > > > */ > > [Shally] It will be good idea to add bit more clarification regarding > > src.offset and dst.offset as well, that is, offset is offset from > > start of very first segment of m_src and m_dst in chained bufs. >=20 > I'd say there should be a separate patch addressing this comment. > This one looks ok to me. >=20 > Acked-by: Pablo de Lara Applied to dpdk-next-crypto. Thanks, Pablo