From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0048.outbound.protection.outlook.com [104.47.42.48]) by dpdk.org (Postfix) with ESMTP id 427F837AC for ; Thu, 28 Jul 2016 13:39:09 +0200 (CEST) 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=Av28JGKpa6bS3+s7Rkk5EVKNXDSAr9QM0o8wH+VivuI=; b=NCtd4wb9M3OZdVSeXzhCjOtt/GSPTgE6Zjhhh/G0WqfEAU3EOc7GHSY6dY09LGBn4l/RJ9ONo4cK+lTdDBFtw69VIcf1p5c9GFbX6iXvMCNoGLVlr/E3u00UPJ1fDKFLVCSYdBKgc62xF0sZieljDUOWMuv8mwZh7nOk2ERYVv4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (12.108.191.226) by BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 28 Jul 2016 11:39:03 +0000 Date: Thu, 28 Jul 2016 17:08:55 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" CC: Thomas Monjalon , "dev@dpdk.org" Message-ID: <20160728113853.GA14755@localhost.localdomain> References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com> <1469114659-66063-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com> <2146153.nVzdynOqdk@xps13> <20160727171043.GA22116@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B8884E@irsmsx105.ger.corp.intel.com> <20160727174133.GA22895@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B88894@irsmsx105.ger.corp.intel.com> <20160728021345.GA3617@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B8AA48@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725836B8AA48@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [12.108.191.226] X-ClientProxiedBy: SN1PR16CA0073.namprd16.prod.outlook.com (10.163.13.41) To BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) X-MS-Office365-Filtering-Correlation-Id: 6ec89de4-cc2a-416f-13db-08d3b6dbc7bc X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 2:Y8klCIu/HJ9FnTjjfOP/rIKVX1ulikwdp7PGDz0JWH1dqwmxgCktckXu4O5m17uzUYcBi8o2MZyKDKhnaKMgNnGe8X7VDIO5Ug1ZRzhwsxaOOrzj1oWhcU3M7xEuN/vJqp5WECJE+HeVjgS0tkFXV2TkGtkJFkCY6fsCBP63ig6zywTTQiYCo+o+oxb9q2/d; 3:rsb7WalGCwTDDbc52cpwPZSDsFLBKJWDDDpnkoP7RjK17RPOmtnn8vlSd6XrFUYymaiJsXdqN49lAsp8ux/hY7+lsp1+qq6mnLqebRI8DLid99VJobZWOylQkbAAYstC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 25:XV1qpB7lbN/hhVRdlvdBDR41YzZGIGCArme9O7rgWGYa8P5iRaVVhSXSlekJ1u1lQRBao1XEw06xaBgynOKFv8Sz8iuImbNnjhqi+/V48+qqE1Dgbq0YWUbAmpN2DqQSBXgN1IyKgM0UO/marN4XlF9bRMnpNRUSgSLn5Z4Vq2IsZyPC392e/IWZFiWIjRI1dewmPqNZz0vCEjVvy8++jgPR2qQHObaYQmiTW5ITeVI4jCsfBYuQOkQg1ldQAqlHHN1RMwS0WOiwG9Und6VBDKBQ+Mda/DbWO1629qD6U0rZCXFqYjSWsw3Ow66WsnD2iWDqy3HEfalTei4VVNe8v88m3m6K4E9NO3XVHfmsdy4QEMgLmJUT7xXZ4x4H8GKsji6OnfEPtYWKPm0Q9wJyHDIqPvM7DfyO4lbHlZG/Dw+odo0Uwk2OOM7VKTUCmyPaYn27I87US97JQvclbBr45Fyml5jz0ThiO03Nc4FT88GwpEzlRRA1n0Gwv/z4OoK9Haag44SDeBBl7oyl7M8FJGFp8RM4Z3iR2ZnA5KySFQTVlqPY70rQGMiHwrEuRU5ihvcll5erzXnCFjMpnCId10sG5OT2fXyP3REBWEio7aQMiL6+oVzzkLEKhIpA4PMuXuk59pXjnPC7loFuOfOgZDEQPfQJJVpQ0umXOnTfkhfEY4pfwAGMFQSk/mZCEnOnlA3OPemgPkbxD1Gqz7TcTsOGRfpDt3RFQkOSdQqprIF2XLeLjNVdAN/6jK+j5AdwxPUzBYnxAJMNy8HaivMrsQ== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 31:gm9IRGDJiIsOrMsd4cTbD3pAobleLQpe613gJI4cZqnZUnNNOiwdL/oABrwPlJPO0vrFLP7TLpdthzRvnw8g3FyNe76Qvh3bSzXUwX6ZBgffC62NHoOhqt+XGpPfA2wShFLgo+LNm+vJSHmx2YMRS0lNRtQzBbna6TKQL7Rd7zfSDjdU133OJznliWSPDWnkUKveeZFdTYlHIztVpU59HQ==; 20:4kQsfM7RPIkdCYb+MwP5QNO9qzgSfds72wnlZj0kFC8pWwUeCvSTASdDuCg9a5S7slMYpoujriWTh0f2EZiqvLMhcKy7McrN/FdOK9WNk8KBX+ft0cVTqUPKKVSp70G6ckhCPg9kGfFNWZKAEoZJg4R/VA0IAoVOUrfzzaZSobNujJE8U0rHDLuTIiJqF7G/ZGKTpViSFoG/W94bYqkYjkZKEmie4l6ONUctnrBXd4VwUuT4+Wh3Y3yyW3FFjt5tyO7LpQT6Z7DgVFXpq9eOUgnzLtLC8Uh9eXsmNk7X/YUtiwaOjAnOkXGCWWwST0FzbEAqP5lQEH2BENtkJWHGe0xUgspSvpi3i6IEYw5j0Vd2s8ZZrMskJsPKANSZLF91KG8M66NH+Y4y08KYbMQhpjNRtkjqsMlpty9Ob4AkS37vQ0KxJVAlncBdYjVgP6cxM4AS79rzf4ZmtuniRsQPewJ8FzP8KV7K5p88EiQmIYah8fhixe3gzRRP3HcS9cxHxdEAz6/gaGty1MKUHik6c6B0HXYGpczZAOvCrhmepRTBWN3VDQzj6M1x3ls2VdJQjFz4rKvhgheaD6ONcYXfHgoeSGy+3NMF87+T6Wffg64= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY1PR0701MB1722; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 4:2lwM+1rsuCpucTl8oTS95UKewoAd8VS6T+wk73BbuV1z0tXC8WyRPQsGj/lAyx/+jNXGX1SXyBAITCafd5D7F1yPRY2Haf31vbbwt3NR8opHD+Z9vF+oi2OPUVfZfwIAtQ/r2QXQweRdhTgaBSnn8DbGPJL7tvTyM/InKVlz/zdIUlep0mafYFb07OKSCGduifGvHhfY4DZcs10eB1bJ1u6+CIsMt7i257MHMuF3uBjDlzkQwUwzry04wUO6mDvVuobNFyanBhrPu7NTMkIdHZftqPekXPqLaKBdiVkFvLRb/8Rpsch3HywnLaIoaZ/Q/IqeWX957WEHBf8q1+eG1Kf6co4aXSvuXJn97jqqLmGAZPBMXDphlkgWOoyGzKHg X-Forefront-PRVS: 00179089FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(189002)(24454002)(199003)(66066001)(8676002)(1076002)(47776003)(23726003)(42186005)(101416001)(2906002)(61506002)(50466002)(105586002)(97736004)(7846002)(7736002)(4001350100001)(106356001)(305945005)(110136002)(189998001)(33656002)(93886004)(586003)(6116002)(46406003)(3846002)(2950100001)(77096005)(83506001)(92566002)(97756001)(68736007)(4326007)(561944003)(76176999)(50986999)(81156014)(81166006)(54356999)(9686002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1722; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1722; 23:mBCMFvVv5Dgg2uxVJLUH2ASATqd/k7P8YG5c/Gb?= =?us-ascii?Q?5GxHFjqo8Ie3feOqDTYtynrziuGuXDITxKQH4YB0efRtzXJn94sW9PiZvsxC?= =?us-ascii?Q?pcqU0XyebHNHLZqEgx791d4noL5K9heFy73+OxMlc+dOqg4e/jfoHizBgqPr?= =?us-ascii?Q?gKaJwuiywbsXV2EyAMvLOm44tLUxobvPhPawHrmrJXjRyIlGEYirGJ4nnCBM?= =?us-ascii?Q?hekuzokvGJSdQfzpEZlX/FQ/KBymy2Vp2JEZM0VeOhecqr4IVwFQuubhPIBZ?= =?us-ascii?Q?RNlOoYkM1J0iaCXF68HQzUnLINq8cDJOuQKiNLjXM+l+1VzJBfEw5J+fwo0R?= =?us-ascii?Q?cZp1dehDVspyoNiVsXM9x/C7TrZCY5xzcIYdV0LdS41I/IwHYoZqGq5pKlwB?= =?us-ascii?Q?Cwxcw8nnVzp94JkPg3LGt6gUGK02vy/d0l+ilhUo33vuslW7sXvpdKS4BX+z?= =?us-ascii?Q?Yi0j0eyaE+DWIjv+rR0aogCF/p4Tu6UPnEbdHvx1I4Fik3IOtvzUdjhabK1L?= =?us-ascii?Q?yvVw8Ndi0r1iQt3DutmaGT4chrfvibAyRXYILPm+mEBDWqq1c0fCHg0GStLw?= =?us-ascii?Q?VvNOmrwYRCiclkgLUHNDg2ABuEO6KeHzBshFfhHPmHfPzK95Dy1ZKWiPaUdd?= =?us-ascii?Q?aGebdlSXjWC7un7cmZyXJ8U6/FP9rOyPV9ieu7c7MEJPiJanUDdaBDIPzyWu?= =?us-ascii?Q?Fix79lmAbQzSXzRkYte48jD4MGpUTkXxiz4BtKiMBde5oi69xJ4pdj2Jpts8?= =?us-ascii?Q?56jRcVde49kIaLPB/PoCYaPPhh9OYStwoaUV5X0Al2gHVYdysEutTEoezzXF?= =?us-ascii?Q?1zIX5kparny2t33XLVCpitejdyqg+ZDqtWNTPa25DgzSqf76t1INjCbaSmtS?= =?us-ascii?Q?LMdX+zpA+koKXjsTRFXCgNeaua+rHItG7J8Msv1HUqRzikq7YdGbqy7LK573?= =?us-ascii?Q?KUH2Fpxku4DdX5v7ERfYDgCrk8ReMEIwbt/7jMwO8rKSmdCbqKDkDu9ZLQT5?= =?us-ascii?Q?AdVcFCWGFKwSW08T06C8u0F7dPStxFO22sM0aNq+iLeBvFgSccio7tO+dBgV?= =?us-ascii?Q?1r4VjWD7UW0rxVN57ttan8mA/1oFFV7usVwwceQ9wJ0Hs1ZKoDASOl56e+LK?= =?us-ascii?Q?JHUzCMPpjdjxcyORH4cKyQZgD5urMmoS9BlCq618EDElHh3mqpHnfpw=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 6:hjoGrPmWLnBaRKbfc0moQlXUAeELYj0V1frjl5JA4xk3o3tq58tmlF2/69/MzZTupOfT7rpQNWl8QB5rTY6nni7teiQIRZmqhSY2CpLNEXc7fazYEzBP9bS6WnSxq1mjw8VLQOIeUYZn4wfQc5NY2CC+uMpUQYthNM71eLjenmgaNoLV9bEYkYdI8iwbULD6wUUeqxt/HlXGQhaBR3ukefP3wDkwtNd1XTXwYe4fCdvFwkORUiOJgBpa/1Va/IlVBRHyYva1lXQy9IZG+EKvMC2JMiqjm0s8ujcYZv+VqdU=; 5:MCjW1gyEWQiXBFMZACgVClPe1OgDBjk05wDzGu+CMwkhuLM6/qPWyIIczJwlhFxJUdZLhAVLBLuxr9ANPWs52u9OP6rwk186H8UzCNK4G9w3myIXZ37wwhgMNtoolR+WbipiIjEvFNJimiWB0+bp3w==; 24:lgcWy9RXrMA7G5YVZXTbgZRTbFSYdwk9KS2uhQ7QzeXdaChzcfUylyNAsyn07qaq8Mfg/ElhAbHV+PfA8/tuBCKeP0IkPJ6l/zndBChr9r4=; 7:CShu2w/tKKytituieOBWYKv2t7ABqbuIKdjD3f8lIs3OWmhTiPf3Zt3ZkLoS9aj+j+keC5DO2gdljwFF3fxoqRLU4XBevUJrj6HuJEeSBsmhn28e2sNQoUX+4o81WhsKgSeq4wc4koU9sLs+lgNI5KEdqRmw0+gVEp/gwhBxjXuyxbrL2P5ESbBJryKtFlFLr4ii9mXdq2BJp/7o8k+YYRk9ZCsTonHuWbdnvPGk3SEbWVwYLIv2nk0lWdQYsuym SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2016 11:39:03.3769 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1722 Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 11:39:09 -0000 On Thu, Jul 28, 2016 at 10:36:07AM +0000, Ananyev, Konstantin wrote: > > If it does not cope up then it can skip tx'ing in the actual tx burst > > itself and move the "skipped" tx packets to end of the list in the tx > > burst so that application can take the action on "skipped" packet after > > the tx burst > > Sorry, that's too cryptic for me. > Can you reword it somehow? OK. 1) lets say application requests 32 packets to send it using tx_burst. 2) packets are from p0 to p31 3) in driver due to some reason, it is not able to send the packets due to some constraints in the driver(say expect p2 and p16 everything else sent successfully by the driver) 4) driver can move p2 and p16 at pkt[0] and pkt[1] on tx_burst and return 30 5) application can take action on p2 and p16 based the return value of 30(ie 32-30 = 2 packets needs to handle at pkt[0] and pkt[1] > > > > > > > > Instead it just setups the ol_flags, fills tx_offload fields and calls tx_prep(). > > > Please read the original Tomasz's patch, I think he explained possible use-cases > > > with lot of details. > > > > Sorry, it is not very clear in terms of use cases. > > Ok, what I meant to say: > Right now, if user wants to use HW TX cksum/TSO offloads he might have to: > - setup ipv4 header cksum field. > - calculate the pseudo header checksum > - setup tcp/udp cksum field. > > Rules how these calculations need to be done and which fields need to be updated, > may vary depending on HW underneath and requested offloads. > tx_prep() - supposed to hide all these nuances from user and allow him to use TX HW offloads > in a transparent way. Not sure I understand it completely. Bit contradicting with below statement |We would document what tx_prep() supposed to do, and in what cases user |don't need it. How about introducing a new ethdev generic eal command-line mode OR new ethdev_configure hint that PMD driver is in "tx_prep->tx_burst" mode instead of just tx_burst? That way no fast-path performance degradation for the PMD that does not need it > > Another main purpose of tx_prep(): for multi-segment packets is to check > that number of segments doesn't exceed HW limit. > Again right now users have to do that on their own. > > > > > In HW perspective, It it tries to avoid the illegal state. But not sure > > calling "back to back" tx prepare and then tx burst how does it improve the > > situation as the check illegal state check introduce in actual tx burst > > it self. > > > > In SW perspective, its try to avoid sending malformed packets. In my > > view the same can achieved with existing tx burst it self as PMD is the > > one finally send the packets on the wire. > > Ok, so your question is: why not to put that functionality into > tx_burst() itself, right? > For few reasons: > 1. putting that functionality into tx_burst() would introduce unnecessary > slowdown for cases when that functionality is not needed > (one segment per packet, no HW offloads). These parameters can be configured on init time > 2. User might don't want to use tx_prep() - he/she might have its > own analog, which he/she belives is faster/smarter,etc. That's the current mode. Right? > 3. Having it a s separate function would allow user control when/where > to call it, let say only for some packets, or probably call tx_prep() > on one core, and do actual tx_burst() for these packets on the other. Why to process it under tx_prep() as application can always process the packet in one core > > > > proposal quote: > > > > 1. Introduce rte_eth_tx_prep() function to do necessary preparations of > > packet burst to be safely transmitted on device for desired HW > > offloads (set/reset checksum field according to the hardware > > requirements) and check HW constraints (number of segments per > > packet, etc). > > > > While the limitations and requirements may differ for devices, it > > requires to extend rte_eth_dev structure with new function pointer > > "tx_pkt_prep" which can be implemented in the driver to prepare and > > verify packets, in devices specific way, before burst, what should to > > prevent application to send malformed packets. > > > > > > > > > > > and what if the PMD does not implement that callback then it is of waste cycles. Right? > > > > > > If you refer as lost cycles here something like: > > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_prep, -ENOTSUP); > > > then yes. > > > Though comparing to actual work need to be done for most HW TX offloads, > > > I think it is neglectable. > > > > Not sure. > > > > > Again, as I said before, it is totally voluntary for the application. > > > > Not according to proposal. It can't be too as application has no idea > > what PMD driver does with "prep" what is the implication on a HW if > > application does not > > Why application writer wouldn't have an idea? > We would document what tx_prep() supposed to do, and in what cases user don't need it. But how he/she detect that on that run-time ? > Then it would be up to the user: > - not to use it at all (one segment per packet, no HW TX offloads) We already have TX flags for that > - not to use tx_prep(), and make necessary preparations himself, > that what people have to do now. > - use tx_prep() > > Konstantin >