From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id D5E70DE3 for ; Wed, 16 Jan 2019 13:09:46 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0GC106a009698; Wed, 16 Jan 2019 04:09:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=ufXea2YXkBeTYWCOh0m9j1HddAoKFkMdudp1Xm3GsXs=; b=X4uLTswB4XFhxpBmT1nNKTASRkPEOT2vRAbozutYT+LA3Nrc13IHvbtyue/A5JWfyf4D OrGq42IpJmyNNQQIeZQ7rV/nHDTyV+dh36so2iiTXLW5peM3qn2TnuuZp9lsSybtAJW5 69taOtwvP3dvLGX6qET7b52zuQiDDfGSdQHD7j3KIbIsF1m5t96Sgg2iCcp9LZNZQgmH Q0b8xA3muX+PVcYYBBNgI+uuMR05baDaVt9/nrh9LJnBKnlT/L0VVUQ/TDEoEnx1A4uL j0GC/dhhTThcCao0wz5iXaLTlBB99YNOMF1p07yyG27WHFbB3el+CEvN2fcHTtV7CQcz qA== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 2q1p42bygj-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 04:09:45 -0800 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 16 Jan 2019 04:09:43 -0800 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.55) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 16 Jan 2019 04:09:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ufXea2YXkBeTYWCOh0m9j1HddAoKFkMdudp1Xm3GsXs=; b=SYzjkoJ2MSHFRQUnAvG0IheBu9u3UxRv16XNCJhNnpEYuFG4//hHoMGKMpHKZYw9J1lDVpgkMUh1W284wr99cc1BiSzkq+ety3Hl4vmco0HcjFJmvNd5kWGsXIW1HPggWHJx4A3JDtpbgk8l//qkdl9DrY69+mHyTlsTaMZ0sfI= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1826.namprd18.prod.outlook.com (10.161.155.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.15; Wed, 16 Jan 2019 12:09:42 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b199:d845:678e:8d72]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b199:d845:678e:8d72%4]) with mapi id 15.20.1516.019; Wed, 16 Jan 2019 12:09:41 +0000 From: Shally Verma To: "Trahe, Fiona" , "De Lara Guarch, Pablo" , "Verma, Shally" , Stephen Hemminger CC: "dev@dpdk.org" , "akhil.goyal@nxp.com" , "Jozwiak, TomaszX" , "Gupta, Ashish" , "Daly, Lee" , "Luse, Paul E" , Anoob Joseph , Tejasree Kondoj Thread-Topic: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done Thread-Index: AQHUhqDGWiQ91k5Oqk2PFjUWQ0rZTKWEsrkAgAD8tICAAL6WgIAirlqAgAjqCTCAAAu9gIAAAH/w Date: Wed, 16 Jan 2019 12:09:41 +0000 Message-ID: References: <1542677988-3876-1-git-send-email-fiona.trahe@intel.com> <20181119175349.2bd2fdd1@xeon-e3> <348A99DA5F5B7549AA880327E580B4358967C84F@IRSMSX101.ger.corp.intel.com> <20181120100703.34c462e9@xeon-e3> <348A99DA5F5B7549AA880327E580B435896A4B55@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435896A5DB3@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435896CAF10@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435896CAF10@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR1801MB1826; 20:/7aoCIla/ZYvPHPOEJSCkQqWpR9DGDP4UQTm5tWZL5Zxv12HG5JErX+zHFrzJ+T0HNK3/GwTb9CYXa+GyomFV4EIGcQ8IItlspGDch8DGxIcbQo2e+5ehnD0EiUViI4yPuTHzpH7UCNpLA3ip056I0AoPVDR0HnFw4WGjExPxwU= x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(376002)(39860400002)(366004)(189003)(199004)(13464003)(110136005)(4326008)(256004)(476003)(8936002)(486006)(14444005)(446003)(11346002)(229853002)(25786009)(7416002)(33656002)(74316002)(68736007)(5660300001)(106356001)(105586002)(2906002)(99286004)(316002)(54906003)(93886005)(53936002)(7696005)(186003)(9686003)(26005)(6116002)(71190400001)(3846002)(107886003)(66066001)(6246003)(97736004)(102836004)(55236004)(14454004)(53546011)(6506007)(305945005)(7736002)(8676002)(6436002)(86362001)(55016002)(478600001)(71200400001)(81156014)(81166006)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1826; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: aef60f42-fb18-4cac-96b9-08d67bab7ec1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR1801MB1826; x-ms-traffictypediagnostic: BN6PR1801MB1826: x-microsoft-antispam-prvs: x-forefront-prvs: 091949432C received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AWxtTwpFCMW74yyw88up8JW/9nMSrhEG6ED6xPOX+YHSxlF+HL9cBUUW+EtQT7NprK2ac01lb2ndEG2fqz6Rrbo+2XZOE2ighZXEsqMHOuW/vZXDErhtrH6o4ImThSS/2ve0piyskCBsUozKvj3i0aKtctop6IrC82YQuKa+w4cdobd5hTLdM38ALFpuNUN6ygF32ZpzJFi8lrUMSQTD7Gv+1fWbv/KxOItl/0NSTbYsLDkEBUqWzjna0RoiHZ31uzLxOejH9utoBLxqSgVyXKiWUktDEwui3SL8n2C7OvNY0Qu4KLNHnbMOqxT2dgKw7a1G+cZc56uFuHXmWuqmOlyGKj5LXZdqIyqL9gfeV2KkxGBqPIL9i6J9kzd+E8/6bm8Or5NmAZdYsJx1cXlHAvl/3bIEYBQ1koMbFR+JSMU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aef60f42-fb18-4cac-96b9-08d67bab7ec1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 12:09:41.4133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB1826 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160102 X-Mailman-Approved-At: Thu, 17 Jan 2019 10:25:34 +0100 Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done 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, 16 Jan 2019 12:09:47 -0000 >-----Original Message----- >From: Trahe, Fiona >Sent: 16 January 2019 17:06 >To: Shally Verma ; De Lara Guarch, Pablo ; Verma, Shally >; Stephen Hemminger >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX ; Gupta, Ashish >; Daly, Lee ; Luse, Paul E ; Anoob Joseph >; Tejasree Kondoj ; Trahe, Fion= a >Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify w= here processing is done > >Hi Shally, > >> -----Original Message----- >> From: Shally Verma [mailto:shallyv@marvell.com] >> Sent: Wednesday, January 16, 2019 11:22 AM >> To: De Lara Guarch, Pablo ; Trahe, Fiona= ; >> Verma, Shally ; Stephen Hemminger >> Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX ; Gupta, >> Ashish ; Daly, Lee ; Luse, = Paul E >> ; Trahe, Fiona ; Anoob Jos= eph >> ; Tejasree Kondoj >> Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify= where processing is done >> >> Hi Pablo, Fiona >> >> >-----Original Message----- >> >From: De Lara Guarch, Pablo >> >Sent: 11 January 2019 00:17 >> >To: Trahe, Fiona ; Verma, Shally ; Stephen >> Hemminger >> > >> >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX ; Gupta, >> Ashish >> >; Daly, Lee ; Luse, Paul E >> ; Trahe, Fiona >> > >> >Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specif= y where processing is done >> > >> >External Email >> > >> >Hi Shally, >> > >> >> -----Original Message----- >> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Trahe, Fiona >> >> Sent: Wednesday, December 19, 2018 5:10 PM >> >> To: Verma, Shally ; Stephen Hemminger >> >> >> >> Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX >> >> ; Gupta, Ashish ; >> >> Daly, Lee ; Luse, Paul E ;= Trahe, >> >> Fiona >> >> Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to spec= ify >> >> where processing is done >> >> >> >> Hi Shally, >> >> >> >> > -----Original Message----- >> >> > From: Verma, Shally [mailto:Shally.Verma@cavium.com] >> >> > Sent: Tuesday, December 18, 2018 10:48 PM >> >> > To: Trahe, Fiona ; Stephen Hemminger >> >> > >> >> > Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX >> >> > ; Gupta, Ashish >> >> ; >> >> > Daly, Lee ; Luse, Paul E >> >> > Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to >> >> > specify where processing is done >> >> > >> >> > >> >> > >> >> > >-----Original Message----- >> >> > >From: Trahe, Fiona >> >> > >Sent: 18 December 2018 20:13 >> >> > >To: Stephen Hemminger >> >> > >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX >> >> > >; Verma, >> >> > Shally >> >> > >; Gupta, Ashish >> >> ; >> >> > >Daly, Lee >> >> > ; Luse, Paul E >> >> > >; Trahe, Fiona >> >> > >Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to >> >> > >specify where processing is done >> >> > > >> >> > >External Email >> >> > > >> >> > >Hi Stephen >> >> > > >> >> > >//snip// >> >> > >> > > Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature fla= g >> >> > >> > > to specify where processing is >> >> > done >> >> > >> > > >> >> > >> > > On Tue, 20 Nov 2018 01:39:48 +0000 Fiona Trahe >> >> > >> > > wrote: >> >> > >> > > >> >> > >> > > > A new device feature flag, >> >> > >> > > > RTE_COMPDEV_FF_SW_OP_DONE_IN_DEQUEUE >> >> > >> > > > is added. A PMD which processes operations using a softwar= e >> >> > >> > > > acceleration engine should set this if the bulk of the >> >> > >> > > > processing is done during the dequeue. It should leave it >> >> > >> > > > cleared if the bulk of the processing is done during the >> >> > >> > > > enqueue (default). >> >> > >> > > > An application may find this useful for tuning. >> >> > >> > > > >> >> > >> > > > Signed-off-by: Fiona Trahe >> >> > >> > > >> >> > >> > > What application? or is this "if we build it they will come?= " >> >> > >> > [Fiona] Our storage team asked for this, so not quite. >> >> > >> > Seems like it might by generically useful, so a bit of the lat= ter >> >> > >> > too :) Would you prefer I removed that line? >> >> > >> >> >> > >> Hopefully, there would be one or more open source projects using= the >> >> API. >> >> > >> I just did a survey of DPDK an 1/3 of it is never used by any op= en >> >> > >> source project. Hate to see more dead code and special cases cr= eated. >> >> > >> >> >> > >> At least, some example code in examples would help. Something li= ke >> >> > >> a simple in memory compressed storage server using a network API >> >> > >> (SMB?/SSH?/FTP?) >> >> > >[Fiona] There is no compressdev sample app yet. >> >> > >However I've double-checked with the SPDK team, they're currently >> >> > >integrating compressdev and intend to push a patch to SPDK - a sto= rage >> >> open-source project - using this flag. >> >> > [Shally] Am seeing some of our HW based PMD also leveraging this >> >> > choice. So I would say to make it generic feature flag instead of S= W specific. >> >> [Fiona] I can do but would like to understand this better first. >> >> My understanding of HW offload is that the enqueue is just packaging = up >> >> the op and sending to the HW. >> >> And the dequeue is just collecting the result from the HW and passing= back >> >> to the op. >> >> The work is done by the HW accelerator, in between those 2 API calls,= not >> >> using any CPU cycles. >> >> So what would it mean for HW to set OP_DONE_IN_DEQUEUE? >> > >> >Any comments on this? I agree with Fiona that this flag makes sense on = SW only, >> >but it seems that you have another use case. >> >> So, after having internal discussions, it is realized this feature will = be useful for particular scenario in >> HW also (though not very common >> in practice but still in use). >> Some hw based PMD, example current octeontx compression, enqueues an op = and wait for it to >> complete >> in enqueue itself to ensure in-order completion and then return. >[Fiona] ok, I understand this point. I'll change the name to >RTE_COMPDEV_FF_OP_DONE_IN_DEQUEUE to accommodate this. [Shally] Ok. that suffice purpose. > >By giving this control to app, it can >> dictate PMD whether >> to wait for its completion in enqueue or dequeue. >[Fiona] I'm not sure if this is a typo or not. You mean it can dictate to = the app where it should wait? >This is a capability flag exported by the PMD, the appl can only query it = to see where the PMD >does the work, NOT set it to tell the PMD where to do the work. [Shally] "it" here referred to app i.e. PMD can expose its capability that = it can do work at either end and then app can state its "preference" where PMD should do work. However looking at= your description, seems I misunderstood a bit.=20 So, would like to understand it bit more on how flag would help app to tune= itself as per current given description?=20 For example, if PMD says, It does actual processing in dequeue, then how it= will impact app design for better performance? Just to avoid confusion, "work" here primarily mean "wait for completion" o= f submitted op in context of HW PMD. For SW PMD, It could be just adding ops in processing ring to be picked up later for ac= tual processing in dequeue. Thanks Shally > > This is useful where out-of-order completion of ops >> negatively impact app >> performance. Such app can use this flag to alter PMD behaviour. Also, we= have another PMD, where it >> internally takes similar >> flag to make this decision, having it exposed will make it more portable= . >> >> Thanks >> Shally >> >> > >> >Thanks, >> >Pablo >> > >> >> >> >> > Thanks >> >> > Shally