From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0087.outbound.protection.outlook.com [104.47.41.87]) by dpdk.org (Postfix) with ESMTP id 797601B2A4 for ; Wed, 14 Feb 2018 06:41:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0M9sbkuLatkcsm+d9OOt/6EH5L6hgnbZ1rnzZx/MpkU=; b=H7TZD4L8tdzknukbc+GQNKmDhJL5V9Agp7YmEqX2r9Z98MaGdP1l6foAl/65op42KPeL80r7//vsvRhH/Mk+dUXB4u1kinYkRfr+M1euiuB2UkMqQNchEQ39YcrmAdIi7CKs0NjMhvJhZXpvQIP6ETJ2ldIkMWkOlkNC1Trg2JY= Received: from CY4PR0701MB3634.namprd07.prod.outlook.com (52.132.101.164) by CY4PR0701MB3747.namprd07.prod.outlook.com (52.132.102.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 14 Feb 2018 05:41:30 +0000 Received: from CY4PR0701MB3634.namprd07.prod.outlook.com ([fe80::a90e:9fcd:9ebd:8cad]) by CY4PR0701MB3634.namprd07.prod.outlook.com ([fe80::a90e:9fcd:9ebd:8cad%13]) with mapi id 15.20.0485.017; Wed, 14 Feb 2018 05:41:29 +0000 From: "Verma, Shally" To: Ahmed Mansour , "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: AdOFUW8Wdt99b3u6RKydGSrxJwvtHgWmWsFg Date: Wed, 14 Feb 2018 05:41:29 +0000 Message-ID: References: <348A99DA5F5B7549AA880327E580B435892F589D@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589315232@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589315AF3@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shally.Verma@cavium.com; x-originating-ip: [117.98.159.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0701MB3747; 7:wLdhlmdZduc5UxNzmX/sBOPPfvna+8CE5bwN61IebsVTPeCDXabHIP0PcOT0dRMuK1gFxnRjFntzv5draMN7gFQB+lu1hOASqKUhMZxVAq9ZsMww0M9Qm/sOWnJ8DtdWrJ5kZYFuTgafVnN6rUWOQo/aq+Z+Hk3nSbUfZ51eyic0to/NynQvPIR3ijeGiQ1HzzlHXpZM+T3YD7PqyfNYr655LsYcsipguvLbb/JDSD1mgywzjvxx6cASQSQA8B7H x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(39380400002)(346002)(396003)(39850400004)(376002)(57704003)(13464003)(189003)(199004)(81156014)(305945005)(72206003)(8656006)(55016002)(25786009)(99286004)(93886005)(66066001)(478600001)(3846002)(6116002)(9686003)(33656002)(26005)(86362001)(2906002)(14454004)(4326008)(3280700002)(102836004)(7736002)(2900100001)(97736004)(2950100002)(3660700001)(5660300001)(59450400001)(110136005)(74316002)(54906003)(316002)(5250100002)(53936002)(106356001)(6436002)(8676002)(105586002)(229853002)(7696005)(76176011)(8936002)(6246003)(81166006)(2501003)(6506007)(186003)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0701MB3747; H:CY4PR0701MB3634.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: b0b7d817-b570-4e20-8f4c-08d5736d98af x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CY4PR0701MB3747; x-ms-traffictypediagnostic: CY4PR0701MB3747: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR0701MB3747; BCL:0; PCL:0; RULEID:; SRVR:CY4PR0701MB3747; x-forefront-prvs: 0583A86C08 received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +ysJqIx55tx0AaJ1Gapbdk3Ikpks8kiPavIrryB44rBBe1mFVRtXEFTyhaTSdjsZ3P5NCg3lYyIrApRtveTm8A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0b7d817-b570-4e20-8f4c-08d5736d98af X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 05:41:29.1971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3747 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 05:41:31 -0000 Hi Ahmed >-----Original Message----- >From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com] >Sent: 02 February 2018 02:20 >To: Trahe, Fiona ; Verma, Shally ; dev@dpdk.org >Cc: Athreya, Narayana Prasad ; Gupta, A= shish ; Sahu, Sunila >; De Lara Guarch, Pablo ; Challa, Mahipal >; Jain, Deepak K ; Hem= ant Agrawal ; Roy >Pledge ; Youri Querry >Subject: Re: [RFC v2] doc compression API for DPDK > >>>> [Fiona] I propose if BFINAL bit is detected before end of input >>>> the decompression should stop. In this case consumed will be < src.len= gth. >>>> produced will be < dst buffer size. Do we need an extra STATUS respons= e? >>>> STATUS_BFINAL_DETECTED ? >>> [Shally] @fiona, I assume you mean here decompressor stop after process= ing Final block right? >> [Fiona] Yes. >> >> And if yes, >>> and if it can process that final block successfully/unsuccessfully, the= n status could simply be >>> SUCCESS/FAILED. >>> I don't see need of specific return code for this use case. Just to sha= re, in past, we have practically run into >>> such cases with boost lib, and decompressor has simply worked this way. >> [Fiona] I'm ok with this. >> >>>> Only thing I don't like this is it can impact on performance, as norma= lly >>>> we can just look for STATUS =3D=3D SUCCESS. Anything else should be an= exception. >>>> Now the application would have to check for SUCCESS || BFINAL_DETECTED= every time. >>>> Do you have a suggestion on how we should handle this? >>>> >> >[Ahmed] This makes sense. So in all cases the PMD should assume that it >should stop as soon as a BFINAL is observed. > >A question. What happens ins stateful vs stateless modes when >decompressing an op that encompasses multiple BFINALs. I assume the >caller in that case will use the consumed=3Dx bytes to find out how far in >to the input is the end of the first stream and start from the next >byte. Is this correct? [Shally] As per my understanding, each op can be tied up to only one strea= m as we have only one stream pointer per op and one stream can have only on= e BFINAL (as stream is one complete compressed data) but looks like you're = suggesting a case where one op can carry multiple independent streams? and = thus multiple BFINAL?! , such as, below here is op pointing to more than on= e streams -------------------------------------------- op --> |stream1|stream2| |stream3| -------------------------------------------- Could you confirm if I understand your question correct? Thanks Shally