From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 59EA9239 for ; Tue, 24 Jul 2018 09:54:05 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 00:54:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,397,1526367600"; d="scan'208";a="56721306" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga007.fm.intel.com with ESMTP; 24 Jul 2018 00:53:59 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 24 Jul 2018 08:53:58 +0100 Received: from irsmsx107.ger.corp.intel.com ([169.254.10.193]) by irsmsx112.ger.corp.intel.com ([169.254.1.22]) with mapi id 14.03.0319.002; Tue, 24 Jul 2018 08:53:58 +0100 From: "De Lara Guarch, Pablo" To: "Verma, Shally" CC: "dev@dpdk.org" , "Athreya, Narayana Prasad" , "Challa, Mahipal" , "Sahu, Sunila" , "Sahu, Sunila" , "Gupta, Ashish" Thread-Topic: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue Thread-Index: AQHUIpS3lxPH6aATzkyBcmdBAApGpqSdXR6AgACRZoCAABIj8A== Date: Tue, 24 Jul 2018 07:53:57 +0000 Message-ID: References: <1532357474-9544-1-git-send-email-shally.verma@caviumnetworks.com> <1532357474-9544-5-git-send-email-shally.verma@caviumnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmVjY2NmZjEtMmI0YS00NmE1LTk3NWQtYTNjODgzNmZlOWM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMU5UXC95TEMxYXZKRTFPYjE0TFdOeTF4MGlzOGVXRGRWSTZVckR0Q1I1dE5iR1lZVEMrVEhJU2RTTEFRM1N4MzMifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue 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, 24 Jul 2018 07:54:06 -0000 > -----Original Message----- > From: Verma, Shally [mailto:Shally.Verma@cavium.com] > Sent: Tuesday, July 24, 2018 8:45 AM > To: De Lara Guarch, Pablo > Cc: dev@dpdk.org; Athreya, Narayana Prasad > ; Challa, Mahipal > ; Sahu, Sunila ; Sahu, > Sunila ; Gupta, Ashish > Subject: RE: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue >=20 >=20 >=20 > >-----Original Message----- > >From: De Lara Guarch, Pablo > >Sent: 24 July 2018 03:55 > >To: Verma, Shally > >Cc: dev@dpdk.org; Athreya, Narayana Prasad > >; Challa, Mahipal > >; Sahu, Sunila ; > >Sahu, Sunila ; Gupta, Ashish > > > >Subject: RE: [PATCH v4 4/5] compress/zlib: support burst > >enqueue/dequeue > > > >External Email > > > >> -----Original Message----- > >> From: Shally Verma [mailto:shally.verma@caviumnetworks.com] > >> Sent: Monday, July 23, 2018 3:51 PM > >> To: De Lara Guarch, Pablo > >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com; > >> mchalla@caviumnetworks.com; Sunila Sahu ; > >> Sunila Sahu ; Ashish Gupta > >> > >> Subject: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue > >> > >> From: Sunila Sahu > >> > >> Signed-off-by: Sunila Sahu > >> Signed-off-by: Shally Verma > >> Signed-off-by: Ashish Gupta > >> --- > >> drivers/compress/zlib/zlib_pmd.c | 255 > >> ++++++++++++++++++++++++++++++++++++++- > >> 1 file changed, 254 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/compress/zlib/zlib_pmd.c > >> b/drivers/compress/zlib/zlib_pmd.c > >> index 47bc73d..dc1e230 100644 > >> --- a/drivers/compress/zlib/zlib_pmd.c > >> +++ b/drivers/compress/zlib/zlib_pmd.c > >> @@ -7,7 +7,214 @@ > >> > >> #include "zlib_pmd_private.h" > >> > >> -/** Parse comp xform and set private xform/stream parameters */ > >> +/** Compute next mbuf in the list, assign data buffer and length, > >> + * returns 0 if mbuf is NULL > >> + */ > >> +#define COMPUTE_BUF(mbuf, data, len) \ > >> + ((mbuf =3D mbuf->next) ? \ > >> + (data =3D rte_pktmbuf_mtod(mbuf, uint8_t *)), \ > >> + (len =3D rte_pktmbuf_data_len(mbuf)) : 0) > >> + > >> +static void > >> +process_zlib_deflate(struct rte_comp_op *op, z_stream *strm) { > > > >... > > > >> + /* Update z_stream with the inputs provided by application */ > >> + strm->next_in =3D rte_pktmbuf_mtod_offset(mbuf_src, uint8_t *, > >> + op->src.offset); > > > >This is assuming that src buffer is a linear buffer or that offset won't= be large > enough to cross boundaries between segments. > >If an SGL is passed and offset is bigger than the first segment, > >next_in should point at a different segment, with the remaining part of > >the offset in that segment (look at ISA-L SGL patch: > http://patches.dpdk.org/patch/43283/). Same applies to avail_in, next_out= and > avail_out. >=20 > [Shally] as per my last knowledge, offset was expected to be belonging on= ly to > the first segment in chained mbuf. Isn't that the case anymore? Did I mis= s any > update on its definition? > We had added the logic earlier that you're suggesting but removed that la= ter, as > I understood clarification about offset falling into any segment is still= pending. >=20 According to the comments: uint32_t offset; /**< Starting point for compression or decompression, * specified as number of bytes from start of packet in * source buffer. * This offset starts from the first segment * of the buffer, in case the m_src is a chain of mbufs. It says that the offset starts from the first segment, but not that it is only applicable for the first segment. >>From my point of view, an SGL should be seen like a contiguous (linear) buf= fer, so if the offset crosses multiple segments, it is still valid, as it is sti= ll part of the buffer. Thanks, Pablo > Thanks > Shally