From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0051.outbound.protection.outlook.com [104.47.1.51]) by dpdk.org (Postfix) with ESMTP id 1E80F255 for ; Thu, 1 Feb 2018 21:50:31 +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=7kATaqvjGm+lxojKueoSCDow/bIkaxLhTnq8Sz0UL7w=; b=U++7wQFXbj9PamNMT5YpsazyWc8z65Nx/ymcbgcxFB6fCB+cgjQrZMo5SvaH5CgGNvkEvjyTll/1iMsRAPBatfmvnrDhRWGneIk9b6jWxSx6JbhmqKSJ3nwTu4oJOunTh5ZgHBrpOjmIlBsklUOu33TaOU5bvDxPvN2V1GysDWA= Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com (52.134.71.143) by DB3PR0402MB3849.eurprd04.prod.outlook.com (52.134.71.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Thu, 1 Feb 2018 20:50:29 +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.0444.016; Thu, 1 Feb 2018 20:50:29 +0000 From: Ahmed Mansour To: "Trahe, Fiona" , "Verma, Shally" , "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: Thu, 1 Feb 2018 20:50:29 +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.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0402MB3849; 7:WHdpf3L2MVz/yICc0pi6DfllZtvTRYbtyoFJS7DYy9By2R1KogWFM1nIVGajOusNQ3KidurOMmOcxPguBOAi89RGtrb4Nzngk97ErpilCatH2OHyFnq5aUxTlPC0V0sWjnqiWifYpL9RTMIUlayG7wDO5Ws4322gbmA+MNVTwyUNIHlbCz5Yhbu5gXMAWw/xhUomCGs8hL14oKLT/KurFIJnbx+4gVTAonXzqSiWlXCa9plLaVPyZPVwMrrD0Paa x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39860400002)(346002)(39380400002)(57704003)(199004)(189003)(26005)(81156014)(81166006)(7696005)(8936002)(76176011)(102836004)(33656002)(97736004)(6506007)(53936002)(2900100001)(5660300001)(2501003)(5250100002)(8676002)(229853002)(55016002)(305945005)(106356001)(9686003)(105586002)(3280700002)(3660700001)(14454004)(68736007)(6436002)(7736002)(66066001)(6246003)(478600001)(25786009)(4326008)(54906003)(86362001)(99286004)(186003)(6116002)(110136005)(93886005)(316002)(74316002)(3846002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0402MB3849; 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: 96284e23-2a31-4430-8739-08d569b56d99 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR0402MB3849; x-ms-traffictypediagnostic: DB3PR0402MB3849: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DB3PR0402MB3849; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0402MB3849; x-forefront-prvs: 0570F1F193 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /Qx7kSuI/5cCrlHCC1aP3LYwpzV4YQgFqrKzrsjU/mq8f/JVFwNOesRX5vw44aNqulXtaxawYk7Qpd+Vee99vQ== 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: 96284e23-2a31-4430-8739-08d569b56d99 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 20:50:29.0630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0402MB3849 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: Thu, 01 Feb 2018 20:50:31 -0000 >>> [Fiona] I propose if BFINAL bit is detected before end of input=0A= >>> the decompression should stop. In this case consumed will be < src.leng= th.=0A= >>> produced will be < dst buffer size. Do we need an extra STATUS response= ?=0A= >>> STATUS_BFINAL_DETECTED ?=0A= >> [Shally] @fiona, I assume you mean here decompressor stop after processi= ng Final block right?=0A= > [Fiona] Yes.=0A= >=0A= > And if yes,=0A= >> and if it can process that final block successfully/unsuccessfully, then= status could simply be=0A= >> SUCCESS/FAILED.=0A= >> I don't see need of specific return code for this use case. Just to shar= e, 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 normal= ly=0A= >>> we can just look for STATUS =3D=3D SUCCESS. Anything else should be an = exception.=0A= >>> Now the application would have to check for SUCCESS || BFINAL_DETECTED = every time.=0A= >>> Do you have a suggestion on how we should handle this?=0A= >>>=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= =0A=