From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0052.outbound.protection.outlook.com [104.47.2.52]) by dpdk.org (Postfix) with ESMTP id D2FD61B29E for ; Wed, 14 Feb 2018 17:55:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GmOP5suMCs7LdNK6lw6hN96XpkkarRGJJ2GOfLUKpV4=; b=R1Dyb87wKjUJauEppYFUPg/f/ZtBdWPZFMY8/yaW4EOvtARDQH8NDKB0WFcoZhItSIudnPal/u+AlT1hQedNSyIEZnE2UDcHLeDJa+Z6OnY91dyyhdaR3i8nZK1mM8wvPHLtXpbIPrZ9lNmYZtGGt+QbFpovwBqtdzvq0nxSBGg= Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com (52.134.71.143) by DB3PR0402MB3690.eurprd04.prod.outlook.com (52.134.70.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Wed, 14 Feb 2018 16:54:59 +0000 Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::bcb3:a74f:d325:7467]) by DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::bcb3:a74f:d325:7467%13]) with mapi id 15.20.0485.016; Wed, 14 Feb 2018 16:54:58 +0000 From: Ahmed Mansour To: "Verma, Shally" , "Trahe, Fiona" , "dev@dpdk.org" CC: "Athreya, Narayana Prasad" , "Gupta, Ashish" , "Sahu, Sunila" , "De Lara Guarch, Pablo" , "Challa, Mahipal" , "Jain, Deepak K" , Hemant Agrawal , Roy Pledge , Youri Querry Thread-Topic: [RFC v2] doc compression API for DPDK Thread-Index: AdOFUW8Wdt99b3u6RKydGSrxJwvtHg== Date: Wed, 14 Feb 2018 16:54:58 +0000 Message-ID: References: <348A99DA5F5B7549AA880327E580B435892F589D@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589315232@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589315AF3@IRSMSX101.ger.corp.intel.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ahmed.mansour@nxp.com; x-originating-ip: [192.88.168.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0402MB3690; 7:ewyeDgaUMwOhZSEgMdReM3UgNNOAdCJscmELLtKmihho+rjNKrS8TvLaIwdGd4mNWAnAeK4NmqYygxVshMU9O5mTmX/1TrXE0IhOnGYlHI061W0dbIigH/7rCf8PvmW9vU/0h0dei3VPnJXdws3Evpuwn5btwDL6exNEGWQy9aSXnQyIbPoLIUMo0vYU/JjUoEbKvCq6sISf3dEPeExip+izeDJLsEwJRAUGCQl6mbNc3beE4aT8LKNhrZPJ0z8h x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(39380400002)(366004)(57704003)(199004)(189003)(13464003)(97736004)(14454004)(102836004)(33656002)(76176011)(105586002)(7696005)(5250100002)(2501003)(229853002)(6506007)(6246003)(53936002)(6436002)(59450400001)(9686003)(7736002)(54906003)(74316002)(305945005)(2900100001)(110136005)(5660300001)(68736007)(55016002)(316002)(53546011)(478600001)(8936002)(99286004)(186003)(3660700001)(26005)(3280700002)(66066001)(86362001)(2906002)(8676002)(93886005)(25786009)(6116002)(106356001)(3846002)(4326008)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0402MB3690; H:DB3PR0402MB3852.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8d75e0ab-0a83-4202-f9fe-08d573cbae8c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR0402MB3690; x-ms-traffictypediagnostic: DB3PR0402MB3690: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DB3PR0402MB3690; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0402MB3690; x-forefront-prvs: 0583A86C08 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YTWXR1zZRbs8oif0i/s78K2x1P/OxfYyKHTuPoCnwxVQTxeJgBdXsPXof93oMvGq6UkfqgEmlqpy6szp8NLaUA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d75e0ab-0a83-4202-f9fe-08d573cbae8c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 16:54:58.6198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0402MB3690 Subject: Re: [dpdk-dev] [RFC v2] doc compression API for DPDK 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: Wed, 14 Feb 2018 16:55:02 -0000 On 2/14/2018 12:41 AM, Verma, Shally wrote:=0A= > Hi Ahmed=0A= >=0A= >> -----Original Message-----=0A= >> From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com]=0A= >> Sent: 02 February 2018 02:20=0A= >> To: Trahe, Fiona ; Verma, Shally ; dev@dpdk.org=0A= >> Cc: Athreya, Narayana Prasad ; Gupta,= Ashish ; Sahu, Sunila=0A= >> ; De Lara Guarch, Pablo ; Challa, Mahipal=0A= >> ; Jain, Deepak K ; H= emant Agrawal ; Roy=0A= >> Pledge ; Youri Querry =0A= >> Subject: Re: [RFC v2] doc compression API for DPDK=0A= >>=0A= >>>>> [Fiona] I propose if BFINAL bit is detected before end of input=0A= >>>>> the decompression should stop. In this case consumed will be < src.le= ngth.=0A= >>>>> produced will be < dst buffer size. Do we need an extra STATUS respon= se?=0A= >>>>> STATUS_BFINAL_DETECTED ?=0A= >>>> [Shally] @fiona, I assume you mean here decompressor stop after proces= sing Final block right?=0A= >>> [Fiona] Yes.=0A= >>>=0A= >>> And if yes,=0A= >>>> and if it can process that final block successfully/unsuccessfully, th= en status could simply be=0A= >>>> SUCCESS/FAILED.=0A= >>>> I don't see need of specific return code for this use case. Just to sh= are, in past, we have practically run into=0A= >>>> such cases with boost lib, and decompressor has simply worked this way= .=0A= >>> [Fiona] I'm ok with this.=0A= >>>=0A= >>>>> Only thing I don't like this is it can impact on performance, as norm= ally=0A= >>>>> we can just look for STATUS =3D=3D SUCCESS. Anything else should be a= n exception.=0A= >>>>> Now the application would have to check for SUCCESS || BFINAL_DETECTE= D every time.=0A= >>>>> Do you have a suggestion on how we should handle this?=0A= >>>>>=0A= >> [Ahmed] This makes sense. So in all cases the PMD should assume that it= =0A= >> should stop as soon as a BFINAL is observed.=0A= >>=0A= >> A question. What happens ins stateful vs stateless modes when=0A= >> decompressing an op that encompasses multiple BFINALs. I assume the=0A= >> caller in that case will use the consumed=3Dx bytes to find out how far = in=0A= >> to the input is the end of the first stream and start from the next=0A= >> byte. Is this correct?=0A= > [Shally] As per my understanding, each op can be tied up to only one str= eam as we have only one stream pointer per op and one stream can have only = one BFINAL (as stream is one complete compressed data) but looks like you'r= e suggesting a case where one op can carry multiple independent streams? an= d thus multiple BFINAL?! , such as, below here is op pointing to more than = one streams=0A= >=0A= > --------------------------------------------=0A= > op --> |stream1|stream2| |stream3|=0A= > --------------------------------------------=0A= >=0A= > Could you confirm if I understand your question correct?=0A= [Ahmed] Correct. We found that in some storage applications the user=0A= does not know where exactly the BFINAL is. They rely on zlib software=0A= today. zlib.net software halts at the first BFINAL. Users put multiple=0A= streams in one op and rely on zlib to stop and inform them of the end=0A= location of the first stream.=0A= >=0A= > Thanks=0A= > Shally=0A= >=0A= =0A=