From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30051.outbound.protection.outlook.com [40.107.3.51]) by dpdk.org (Postfix) with ESMTP id 82DF52BE5 for ; Wed, 14 Mar 2018 20:02:27 +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=65joA9F0jzzD2qLmytSBZ7umcf+HV9YhJEIuNe3Tn24=; b=Cv6qFdU3K5EbFn1t1CexVPOoxQPfs2BEvKgBWLLNGZbQ2veCP3SXbMRXiHFb58Yoa9bEpP0AJbFWyoHAPcmTfnXmsJ4WNkrgY8u4TZ1GT1YQ0xaRFwZQWFho7R3JdR3SflSOMn1RVffrVAdtgBNRaTcUVKe1pAN/K8KjZ22T6Kw= Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com (52.134.71.143) by DB3PR0402MB3691.eurprd04.prod.outlook.com (52.134.70.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Wed, 14 Mar 2018 19:02:25 +0000 Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::8554:d533:15e:1376]) by DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::8554:d533:15e:1376%13]) with mapi id 15.20.0548.021; Wed, 14 Mar 2018 19:02:24 +0000 From: Ahmed Mansour To: "Trahe, Fiona" , "Verma, Shally" , "dev@dpdk.org" CC: "De Lara Guarch, Pablo" , "Athreya, Narayana Prasad" , "Gupta, Ashish" , "Sahu, Sunila" , "Challa, Mahipal" , "Jain, Deepak K" , Hemant Agrawal , Roy Pledge , Youri Querry , "Daly, Lee" , "Jozwiak, TomaszX" , Alok Makhariya , Shreyansh Jain Thread-Topic: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alternative Thread-Index: AdO6FqZGVQESVGJPRLukdFdKpdlnig== Date: Wed, 14 Mar 2018 19:02:23 +0000 Message-ID: References: <348A99DA5F5B7549AA880327E580B435893478BA@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358934A600@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358934B32C@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; DB3PR0402MB3691; 7:mWr8ct2tyTqyqsjqpoumL6hVotZpwH6Yu7sFG0HV8u/Ao4/4tXpdCl+Eb8AZso/xCFGLCRuKwmPXS7vDuJQOUVPowNYPdM53nQIslmxHFQ5FAX5WkA/S7lvdb91qJ+uQ/newD6OdRy3sYdfRrq5FO8U/Tp3SUO8EExkmYmtjrL5S0oqs2FKfcyz02A281t7irAfy+ZeCRs4Amca8mWBTKftnlAJc66MYpazzDtJlttb03QjcQFKPBu3+IIsp/eow x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(39380400002)(376002)(366004)(39860400002)(346002)(53754006)(13464003)(189003)(199004)(5660300001)(561944003)(6506007)(7416002)(68736007)(229853002)(81166006)(25786009)(81156014)(3846002)(316002)(93886005)(8936002)(33656002)(6116002)(6436002)(106356001)(86362001)(14454004)(97736004)(55016002)(305945005)(105586002)(2906002)(74316002)(45080400002)(8676002)(53546011)(5250100002)(99286004)(3280700002)(2900100001)(3660700001)(102836004)(2501003)(6246003)(7696005)(478600001)(7736002)(53936002)(4326008)(76176011)(9686003)(110136005)(59450400001)(966005)(66066001)(6306002)(26005)(54906003)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0402MB3691; H:DB3PR0402MB3852.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2d889b3a-c91d-4ca1-ccee-08d589de1f1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0402MB3691; x-ms-traffictypediagnostic: DB3PR0402MB3691: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(189930954265078)(185117386973197)(85827821059158)(788757137089)(45079756050767)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501244)(52105095)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DB3PR0402MB3691; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0402MB3691; x-forefront-prvs: 0611A21987 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9kIUUH04io54X4FAp7zP+FbzHIcHFculpYa8eadABfOT+g86bxQ08SFwYTNA3E2D17rj0S3MaU5R7p5oDw6FgA4I3KEAeMV7lLID9VQgq5+78cjp2AvmtvZ0VLTUXKdnMH0T4OYFTHV8ysAO4JzpvZ/1Un+huoEugaKDY8Ge0nMjNHMJvKerT/Bm+T54zYuFYwjhvyWc03Jd6N9QFXYvFvVMNGpqRMIvkVKzClOHAPGqBjxKy7IjXaIEtkK1u+S+qcvj7Gax0n5Mg21GaL46UK6aMN3T0cDgaaURxkmvnV5NB7YqJCLs5pDO+Ua3Qv46/1aEjqq07LNrLOXy+3NRGA== 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: 2d889b3a-c91d-4ca1-ccee-08d589de1f1e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2018 19:02:23.9556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0402MB3691 Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alternative 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 Mar 2018 19:02:27 -0000 Hi All,=0A= =0A= Sticking with mbufs until at least 1805 works for us. We also see=0A= storage as the main use case, but ipcomp maybe an important customer use=0A= case in the future. Nonetheless, I see the mbuf formatting as inherently=0A= external to the compressdev APIs. An application doing ipcomp should=0A= just do the mbuf packaging outside of compressdev. At least that is what=0A= current software implementation of ipcomp do when using zlib.net. I am=0A= assuming that transferring from mbuf to regular buffers and back does=0A= not involve some time consuming work like data copying and such.=0A= =0A= Thanks,=0A= =0A= Ahmed=0A= =0A= On 3/14/2018 2:39 PM, Trahe, Fiona wrote:=0A= > Hi Shally, Ahmed, et al,=0A= >=0A= > Following internal and community feedback we've decided that there's stil= l too much churn in this. =0A= > We're proposing, in the interest of getting the API out in 18.05, to stic= k with mbufs - acknowledging=0A= > that they're not optimal for storage and we may propose changes in 18.08.= =0A= > Compressdev will start as an experimental API in 18.05 - we'll POC and be= nchmark alternatives =0A= > or API extensions once we get time to do so.=0A= >=0A= > Regards,=0A= > Fiona=0A= >=0A= >> -----Original Message-----=0A= >> From: Verma, Shally [mailto:Shally.Verma@cavium.com]=0A= >> Sent: Wednesday, March 14, 2018 12:51 PM=0A= >> To: Trahe, Fiona ; Ahmed Mansour ; dev@dpdk.org=0A= >> Cc: De Lara Guarch, Pablo ; Athreya, Nar= ayana Prasad=0A= >> ; Gupta, Ashish ; Sahu, Sunila=0A= >> ; Challa, Mahipal ; J= ain, Deepak K=0A= >> ; Hemant Agrawal ; Roy = Pledge=0A= >> ; Youri Querry ; Daly, Lee <= lee.daly@intel.com>;=0A= >> Jozwiak, TomaszX =0A= >> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf altern= ative=0A= >>=0A= >>=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=0A= >>> Sent: 13 March 2018 21:22=0A= >>> To: Verma, Shally ; Ahmed Mansour ;=0A= >> dev@dpdk.org=0A= >>> Cc: De Lara Guarch, Pablo ; Athreya, Na= rayana Prasad=0A= >> ;=0A= >>> Gupta, Ashish ; Sahu, Sunila ; Challa, Mahipal=0A= >>> ; Jain, Deepak K ; = Hemant Agrawal=0A= >> ; Roy=0A= >>> Pledge ; Youri Querry ; Dal= y, Lee=0A= >> ; Jozwiak, TomaszX=0A= >>> ; Trahe, Fiona =0A= >>> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alter= native=0A= >>>=0A= >>> Hi Shally,=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Verma, Shally [mailto:Shally.Verma@cavium.com]=0A= >>>> Sent: Tuesday, March 13, 2018 8:15 AM=0A= >>>> To: Trahe, Fiona ; Ahmed Mansour ;=0A= >> dev@dpdk.org=0A= >>>> Cc: De Lara Guarch, Pablo ; Athreya, N= arayana Prasad=0A= >>>> ; Gupta, Ashish ; Sahu, Sunila=0A= >>>> ; Challa, Mahipal ;= Jain, Deepak K=0A= >>>> ; Hemant Agrawal ; Ro= y Pledge=0A= >>>> ; Youri Querry ; fiona.tra= he@gmail.com; Daly, Lee=0A= >>>> ; Jozwiak, TomaszX =0A= >>>> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alte= rnative=0A= >>>>=0A= >>>> HI Fiona=0A= >>>>=0A= >>>> So I understand we're moving away from mbufs because of its size limit= ation (64k) and cacheline=0A= >> overhead=0A= >>>> and their more suitability to n/w applications. Given that, I understa= nd benefit of having another=0A= >> structure=0A= >>>> to input data but then what is proposal for ipcomp like application wh= ere mbuf usage may be a better=0A= >>>> option? Should we keep support for both (mbuf and this structure) so t= hat apps can use appropriate=0A= >> data=0A= >>>> structure depending on their requirement.=0A= >>> [Fiona] An application can use pass buffers from an mbuf or mbuf chain = to compressdev by filling in the=0A= >>> compressdev struct fields with the mbuf meta-data, using rte_pktmbuf_da= ta_len(),=0A= >>> rte_pktmbuf_mtod(), rte_pktmbuf_mtophys(), etc=0A= >>> For simplicity I'd prefer to offer only 1 rather than 2 data formats on= the API.=0A= >>> We see storage applications rather than IPComp as the main use-case for= compressdev, so would prefer=0A= >>> to optimise for that.=0A= >>> Do you think otherwise?=0A= >> [Shally] Yea. We plan to use it for ipcomp and other such possible n/w a= pps. So, we envision mbuf support=0A= >> as necessary. So, I think we can add two APIs one which process on rte_c= omp_op and other on rte_mbufs=0A= >> to make it simpler.=0A= >>=0A= >>>> Further comments, on github.=0A= >>>>=0A= >>>> Thanks=0A= >>>> Shally=0A= >>>>=0A= >>>>> -----Original Message-----=0A= >>>>> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=0A= >>>>> Sent: 12 March 2018 21:31=0A= >>>>> To: Ahmed Mansour ; Verma, Shally ;=0A= >>>> dev@dpdk.org=0A= >>>>> Cc: De Lara Guarch, Pablo ; Athreya, = Narayana Prasad=0A= >>>> ;=0A= >>>>> Gupta, Ashish ; Sahu, Sunila ; Challa,=0A= >> Mahipal=0A= >>>>> ; Jain, Deepak K = ; Hemant Agrawal=0A= >>>> ; Roy=0A= >>>>> Pledge ; Youri Querry ; f= iona.trahe@gmail.com;=0A= >> Daly,=0A= >>>> Lee ;=0A= >>>>> Jozwiak, TomaszX =0A= >>>>> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alt= ernative=0A= >>>>>=0A= >>>>> Hi Shally, Ahmed, and anyone else interested in compressdev,=0A= >>>>>=0A= >>>>> I mentioned last week that we've been exploring using something other= than mbufs to pass src/dst=0A= >>>> buffers to compressdev PMDs.=0A= >>>>> Reasons:=0A= >>>>> - mbuf data is limited to 64k-1 in each segment of a chained mbuf. Da= ta for compression=0A= >>>>> can be greater and it would add cycles to have to break up into sm= aller segments.=0A= >>>>> - data may originate in mbufs, but is more likely, particularly for s= torage use-cases, to=0A= >>>>> originate in other data structures.=0A= >>>>> - There's a 2 cache-line overhead for every segment in a chain, most = of this data=0A= >>>>> is network-related, not needed by compressdev=0A= >>>>> So moving to a custom structure would minimise memory overhead, remov= e restriction on 64k-1 size=0A= >> and=0A= >>>> give more flexibility if=0A= >>>>> compressdev ever needs any comp-specific meta-data.=0A= >>>>>=0A= >>>>> We've come up with a compressdev-specific structure using the struct = iovec from sys/uio.h, which is=0A= >>>> commonly used by storage=0A= >>>>> applications. This would replace the src and dest mbufs in the op.= =0A= >>>>> I'll not include the code here - Pablo will push that to github short= ly and we'd appreciate review=0A= >>>> comments there.=0A= >>>>> https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= github.com%2Fpablodelara%2Fdpdk-draft-compressdev&data=3D02%7C01%7Cahmed.ma= nsour%40nxp.com%7C6a8977f9b3714d58621708d589dae567%7C686ea1d3bc2b4c6fa92cd9= 9c5c301635%7C0%7C0%7C636566495639618830&sdata=3DwmFrxeUNyXdxI5%2Fp5gCmyIRfe= DnbHebBJXbztqdsMrc%3D&reserved=3D0=0A= >>>>> Just posting on the mailing list to give a heads-up and ensure this r= eaches a wider audience than may=0A= >> see=0A= >>>> it on github.=0A= >>>>> Note : We also considered having no data structures in the op, instea= d the application=0A= >>>>> would supply a callback which the PMD would use to retrieve meta-data= (virt address, iova, length)=0A= >>>>> for each next segment as needed. While this is quite flexible and all= ow the application=0A= >>>>> to keep its data in its native structures, it's likely to cost more c= ycles.=0A= >>>>> So we're not proposing this at the moment, but hope to benchmark it l= ater while the API is still=0A= >>>> experimental.=0A= >>>>> General feedback on direction is welcome here on the mailing list.=0A= >>>>> For feedback on the details of implementation we would appreciate com= ments on github.=0A= >>>>>=0A= >>>>> Regards,=0A= >>>>> Fiona.=0A= =0A= =0A=