From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0073.outbound.protection.outlook.com [104.47.40.73]) by dpdk.org (Postfix) with ESMTP id F3DEA378E for ; Wed, 21 Sep 2016 10:30:20 +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=JmR0PItcvI/jgTHE+rfU/nhc0mkHM2YxXRo+0r4Xo40=; b=PE8QN68/D8hZKukJwY97GxB/+ovWRSqsYichx2h+kDMu3dQDUxhANXknXLHyteVSU3yrxnurQ37krd2Btr6+p7+6xoMlZehvbCeo2tSssxLMsSan3pANRskqEmwi5zohq4mtRNcwaK4ddiW90g2r1inPeF8krmTL+krekHyhBSE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.167.187.3) by BY1PR0701MB1723.namprd07.prod.outlook.com (10.162.111.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Wed, 21 Sep 2016 08:30:16 +0000 Date: Wed, 21 Sep 2016 13:59:57 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" CC: "Kulasek, TomaszX" , "dev@dpdk.org" Message-ID: <20160921082956.GA5358@localhost.localdomain> References: <1472228578-6980-1-git-send-email-tomaszx.kulasek@intel.com> <1473691487-10032-1-git-send-email-tomaszx.kulasek@intel.com> <1473691487-10032-2-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB9772583F0B583F@irsmsx105.ger.corp.intel.com> <3042915272161B4EB253DA4D77EB373A14F1A294@IRSMSX102.ger.corp.intel.com> <20160919160630.GA18610@localhost.localdomain> <2601191342CEEE43887BDE71AB9772583F0B8F33@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0B8F33@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-Originating-IP: [122.167.187.3] X-ClientProxiedBy: MAXPR01CA0059.INDPRD01.PROD.OUTLOOK.COM (10.164.146.159) To BY1PR0701MB1723.namprd07.prod.outlook.com (10.162.111.142) X-MS-Office365-Filtering-Correlation-Id: 9bb70c11-854b-4a8e-c4e3-08d3e1f9849d X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 2:sKet7vaGlnIB4hqIZre1S3RokfpuhaBLtLBDwryah4Xr4SqicBbhrc/1jwcJSJa938X49A1x5bEZMod6jmJROiiNe5BeQt058lN3R3aann7f6eGDwSel1wwaKDfgPoSC86JnIE/zTp0bFsLHXTbJRQgVaNRRO8IgvlI0+gRE8/WRH1ETjRVOw0e5NPcRKknJ; 3:O6tv+s6Aa8j2GKrVBwH3m8r1tAoPe3kzKidbqazRuAxosox0UKGI8ldrvkW+A5PV30MJ2bYphnF+Y/WcycuMxi4VLKistT3+3x3+3IDrlswPFqhFdJn4McWzQrWhPpY4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 25:Ny1RuT1iota9olUjmhzMUiO5r0S5SAGf1OgqGIoBeZX4D/dHNYI//iQEJyTV46uPA/rPZOd/nWn6cC/Sv4Gld7V6n60eu3xaf9zfPGNjpUG3olIBoiKW+J6ky7yj3WQuWiDZgEqnOAu052qiIf7HsFqkQIAIWpb+Rg6IT7FzEtN2pQ6RpqQphX3LvsHT7yoOxIcuie6vjP2eUCbNFkIxBNEZf2m4cz69kVmcxJyEMP+x8OHAqnCoXauLxNmbsFF9dL6VCcanBxZ5XhnTyqZwXtmEd+4iEsdXtcJSGPFVukV6O5YuXQwUBDOkmjnp+evKHxvY3xd/Dd8bNKHaBRzhBRIpz8TnOZXUsZV16hpEFCaFUIbfIiunO6U4Vs4+iAbSUYMGhev8fsdO2uoIXhTn0M31vsggpU78PdzZm92bjdSL7cZGPPAnwOtBPzAVGNIi2QHi5dKH3DNcyudw3ZBFkx28YSjRV2jCSwgYJqpWKvm4jVkm639xGP8SAZFxWfSWUkIUs4B5xYTkprJEXjHHn97QG1xddu/eJ7+SmRQOSu701Hb9SbpH9C1ymGLIg1fgGs5bourFfqkX64hnMQFPPQR4Iy3vBwG3Ko3bQKAK9V2BUCydhnihEuLl3fs4gFdXdXfKkVpohTK0J/x7yNxG6cVKT1hBBOs8v9C/xidsapnIto4RxKJG8QuGAe0ELhcTE4U1mc8mHCW64RNy0LFpsU67L2WZhbsbV6lWpR4uQ8RLqoGbI8pWQHTxF+n+IS9pND4jXv8R6OVoXCX0bIrmbAXpUqCvTOACUFV4fGc5DkutaKJeSV9Cb2tpMOMHLCtEpzc0F+J6xyRfW+l/pGMw9ErDgXxZ5zxE6yRX/moLGS4= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 31:GIMQHJA1WNBI5FolELGqkivJmJzcdybMme8T3DMeTIKxvJIXGYuDbFW2DOHSllqe2t6KthRschrxnhfU34CPZXjNR0V+jKb27zeeXLocqNcMgcdMQk7phtezof5186NEJfBObeOpZXewDCrkMhMQa10u+XJA9MlZ5oMZvqf8gaI5NjPBycCDmvsW2xvMrER71FB3UhZZT5EEbv1zH6Aa7ySsBxWfPkMXq4Di5U9AfNU=; 20:mlPMsck+aOb29U+cmkSpB+uRxPIKYVh42gFrDvq0zQTTlIp7OBpGcNIXE9UYtziWlwCqi8ZoZRrEVwYp/mK1et4TdvPfpOHj3U2GiVA1YxLSL9eLcz8yy63CrMYvFInOtNJmr+FnkzY4lX1PvXf6ex+nXZOLV0x0ekuv7BjIDW1imPxQqOPJdPSheJI7TRNJ4jRK7vomjV7/yMOO5X8BjPOvMC3iCmt1UJOr5sr44XZkMRCvaictFVltvBa26aAkNVWMPs4cXvfthSaS2tcahpmLE2FyaR5TJwTAwy1lDUD1euUcgljNf09UrnLb6rLWn6H+4+U+rwOc/ZCEBoMFvnnSqEpCIXOZfIvWwvIogjJXqkRMpFw7dp5bxxkMXT/sjvxzgrDX4wV/ng6CGjpkkpW72Oxhh1Sifc0Bhma45C2VgU2EOUmp3bDf5bueuSXuPM9ZRH8QQWdu4TDm61EtU2efbN0W457RmpbmLMIaXwP5jzj+/oojfLdhnkRYWMyG2gj1sj5js6uto5CM+DMfHjgJtglTYjqMOFWQiWY7wWa5H3fmqPiV4/h0+biAWXXPk8llJ6PnXOIWTB/xK+OZQWbOfMhUuP+Fdx0lZ8zxM/c= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR0701MB1723; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 4:knU+R37RwIz8g+U08EwmEv76FQxswfl+qcwyxGXoNRHgtzLQCv5p7q9oHJgI7dArRAPQX5sqx16tMNcGWvQwlb8Il5dRAOx0ubh1X/XVdSL7R7hiBOWaSCeX/SO/exw+E/2rjcBcET6EhlITde6ZJwzp7WikYBfI3urtizhC5xHwkS8McjD6+kAmDtLzEi5yl/q1WE7lvrem8lot1tDbJ1GX63H86WVRtao20mEnRiihVqYXMPfqjWR/zE+BWxcYR0tm7LTAr3Gb78tYa3n8wAv0Z0cjzjk5oaF5fh6g6dq1ZNEYXOjBipv4b0byO+6TsPhkkNdmYt2R4LHVcjkHomBepgYhenbEJPe9tceiWsFuy3kf5YsfkxCL4/7Two4GJBwUafD7YOoeEK2+hIaZW73a2d0dlpW8qnjFKE2g81G7OiclIXnF/muN8a5+/pQf X-Forefront-PRVS: 007271867D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(199003)(189002)(24454002)(3846002)(6116002)(586003)(4326007)(93886004)(1076002)(54356999)(50986999)(97756001)(76176999)(50466002)(46406003)(101416001)(9686002)(2906002)(23726003)(105586002)(106356001)(5660300001)(42186005)(1720100001)(68736007)(4001350100001)(110136003)(7736002)(92566002)(15975445007)(83506001)(97736004)(77096005)(8676002)(81166006)(81156014)(66066001)(19580395003)(189998001)(2950100001)(47776003)(33656002)(15395725005)(7846002)(305945005)(61506002)(7099028)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1723; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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; BY1PR0701MB1723; 23:7/fp8bt1ILwZxAxMrmtLhdaBZTbuyBJPB+USWsE?= =?us-ascii?Q?RUyr2RQVJaM3mvDz476X7dVk5/clBGCFIpvfCrzl+K/rstVmEVij1osBTxyv?= =?us-ascii?Q?5IRYQAlwnMkr8o7PqQ4wOVwWv4W8jVq4SCuQL8RmXN5Csq7T7FNDI9Ji1DN5?= =?us-ascii?Q?88oeZwAFKL0bE2hvfXqQ6yZ9+9P38yHvu0Q6/HFz8dK3bDKm0Hh7AvnautlS?= =?us-ascii?Q?SFlMgZjIrJTUpFruEZL8LWlzKQwvJaFyOx/Zm9vNehNytDVCiQDzx6kcd/oS?= =?us-ascii?Q?6bPQxS2ZgGJcikalHETf4VXgx/MK4mcltMupn3C8yr6pHqOOXHnVRl0pxpQ+?= =?us-ascii?Q?r6C/QuMccei/BnkNqS6FMZ7IxlsP2xTnvNsmezee7+OWTlYK2egg8Rt/VdXQ?= =?us-ascii?Q?UiTEMSFqbofV4K1oRU7mDcyph448rpd5L5NlqSFg6o5BovOvWihHipaAxEyt?= =?us-ascii?Q?PHG4BhWrUvLEJStXMwSdRZRB02nKobFg6RZoxtRJBV/BdKP5ns6CRcdcAgql?= =?us-ascii?Q?b5vQHSr2Sj3+jxubjSios10Nsaw1OeuSMweiiAKfeoDamz7LGGF2XqV7FhtI?= =?us-ascii?Q?9A+DNEdilUNfXVv+n43e787h0Lh7d3wVdJtYhx6uDbZyv3QqlQJzB6m5gR/i?= =?us-ascii?Q?9FKA5zYZa5DG/LFyC+n3pWU2tycAGezRycwpZeefwAmO2ynO5cF4sGC1Rf5H?= =?us-ascii?Q?0WSLqSXxK1LdpRAQzEyb++4u+6WHwF8f5LKVrr1dlU27hPJTjQG6VB6G0OVH?= =?us-ascii?Q?VqtoNggqEDSLIY12vQBwGXFEy3bWDhZtyYI7E0wWH+jHwZS4zpS5EXeqE+2Y?= =?us-ascii?Q?e6TUtGwufJGLMRljQYVWsvzg1Z1blxopZyqNLzortOER43CQh1IrvwzaMGuG?= =?us-ascii?Q?U1+ZW+41NnD+x8tCc7UD0Nk3AZBAqKMfImwf1m+3h/aRTYVofcAvIM5KYQEA?= =?us-ascii?Q?YX1j+09pc3wjBxMwUB+GKX+7W12w+DYm1c7LNFQTVOqtnfB1klHrrPLNUxT9?= =?us-ascii?Q?zcYs9ralaxYM50+RO4XLyOHg1HGCyKuDe3aluFXOaQD84midTBu6Va6DC2gQ?= =?us-ascii?Q?oQJKb9X8Ok+ng2nFtrP+zXau7sjdFRksWXRGjK2K4ceS+X/xT0p6Sl+RzAK5?= =?us-ascii?Q?iBPF6vD0IxQk5G1cTeCHkXBIZKsLFB93+07BJ21GPGy+UNyX1vv+RjuBpFQ6?= =?us-ascii?Q?ID9Ns0Umea1auAGtzOqUkm/1fB0pObvNARbpC3Zr3NiY0w9GRkkMO0zaQfv9?= =?us-ascii?Q?2Lxllc3josVUI9iDRki99tgUNKjNmBe4MqL9IuNdDC3Rnv0OuEkKFCPumKMb?= =?us-ascii?Q?Kxw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 6:Vsk4cMmrxfd6C6+vehFiv+j4ssjy00Pw2UficDtRyS7SSdmMqqC7aLbcT0R21gH8OGlvllXPz2GCnRJBLu+fe+Q/mwWHG4Rku5bpFc6T6N2ckWqO0e/HYfVXRFdmLBpUpP9mX9856FNsEbREPiIokD+lGj5EVKTdLpZMaheBj4thaepOkXLR/0mgqeyb2jmMg1KjtacClcz+sSK1rbYbKogCShkAbnrBTTG1zPW9LZgIKtuxFVnjZihXV6yEM3J8K2/PWNsNehxviVeYdotcdojSEeWSgjGthLUAKCBB66A=; 5:U7Yfi6PF8DCHjuc9708QV09AnlkG6R/R2FPPCZP7fzAY+pyvqynbdplNfj9tPhOgLV2v0tQmBb0YW65+AtLzzrn7/3UGjjp967zZ4avQL+oxtfxZKRvV1LPz4TiKgZqt/5NkYRM0MlMjy88dv5g3NA==; 24:YIEn2kbOnBBKZwT9Dn9A98d3Z51L/nMfstRLhhSmFPgjjKUS1/w4DcUxyqhT5xP7K+mpisSIwFojnFkVIpCDLqeQ63ZBJLzO9qbwe9Ij5+c=; 7:TgiTMCxwIJ2xCHhxmP/JSPjF/hs3kpu9z6R0j4KgkzrfTOEzw3J0qq7W9o1SnpWlV47MVRlLyo8Zt76SANou2h91oXSglZQAFr2RXMksxKPhBRH0ae5xoa+qdNDIIxseX2Ax0d5SSjG9etMM/yKXAol8aul+mkvxdU7wNd+y5MyuuUmhwQ6sWsGRNr7dKQn9Gop8CJXKHru+wpBEhHGIlFh1gBHWj/SoOeCnmb1UV5IH6Cv2SHqC5ezWgvD6xoOR54n1H+C5tAFybWV2dJ4yyYgbZ/Qr6vegpiU2pmpRbU9KeKjrWBu+KWZwkpTbUD+7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2016 08:30:16.3657 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1723 Subject: Re: [dpdk-dev] [PATCH v2 1/6] ethdev: add Tx preparation 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: Wed, 21 Sep 2016 08:30:21 -0000 On Tue, Sep 20, 2016 at 09:06:42AM +0000, Ananyev, Konstantin wrote: > > Hi Jerin, Hi Konstantin, > > > > > > > > > > > > [...] > > > > > > > > + > > > > > +#ifdef RTE_ETHDEV_TX_PREP > > > > > > > > Sorry for being a bit late on that discussion, but what the point of > > > > having that config macro (RTE_ETHDEV_TX_PREP ) at all? > > > > As I can see right now, if driver doesn't setup tx_pkt_prep, then > > > > nb_pkts would be return anyway... > > > > > > > > BTW, there is my another question - should it be that way? > > > > Shouldn't we return 0 (and set rte_errno=ENOTSUP) here if > > > > dev->tx_pk_prep == NULL? > > > > > > > > > > It's an answer to the Jerin's request discussed here: > > > http://dpdk.org/ml/archives/dev/2016-September/046437.html > > > > > > When driver doesn't support tx_prep, default behavior is "we don't know requirements, so we have nothing to do here". It will simplify > > application logic and improve performance for these drivers, I think. Catching this error with every burst may be problematic. > > > > > > As for RTE_ETHDEV_TX_PREP macro, suggested by Jerin in the same thread, I still don't think It's the best solution of the problem > > described by him. I have added it here for further discussion. > > > > > > Jerin, have you something to add? > > > > Nothing very specific to add here. I think, I have tried to share the rational in, http://dpdk.org/ml/archives/dev/2016- > > September/046437.html > > > > Ok, not sure I am fully understand your intention here. > I think I understand why you propose rte_eth_tx_prep() to do: > if (!dev->tx_pkt_prep) > return nb_pkts; > > That allows drivers to NOOP the tx_prep functionality without paying the > price for callback invocation. In true sense, returning the nb_pkts makes it functional NOP as well(i.e The PMD does not have any limitation on Tx side, so all packets are _good_(no preparation is required)) > What I don't understand, why with that in place we also need a NOOP for > the whole rte_eth_tx_prep(): > +static inline uint16_t > +rte_eth_tx_prep(uint8_t port_id __rte_unused, uint16_t queue_id __rte_unused, > + struct rte_mbuf **tx_pkts __rte_unused, uint16_t nb_pkts) > +{ > + return nb_pkts; > +} > + > +#endif > > What are you trying to save here: just reading ' dev->tx_pkt_prep'? > If so, then it seems not that performance critical for me. > Something else? The proposed scheme can make it as true NOOP from compiler perspective too if a target decided to do that, I have checked the instruction generation with arm Assembly, a non true compiler NOOP has following instructions overhead at minimum. # 1 load # 1 mov if (!dev->tx_pkt_prep) return nb_pkts; # compile can't predict this function needs be executed or not so # pressure on register allocation and mostly likely it call for # some stack push and pop based load on outer function(as it is an # inline function) return (*dev->tx_pkt_prep)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts); # 1 branch if (unlikely(nb_prep < nb_rx)) { # bunch of code not executed, but pressure on i cache int i; for (i = nb_prep; i < nb_rx; i++) rte_pktmbuf_free(pkts_burst[i]); } >>From a server target(IA or high-end armv8) with external PCIe based system makes sense to have RTE_ETHDEV_TX_PREP option enabled(which is the case in proposed patch) but the low end arm platforms with - limited cores - less i cache - IPC == 1 - running around 1GHz - most importantly, _integrated_ nic controller with no external PCIE support does not make much sense to waste the cycles/time for it. cycle saved is cycle earned. Since DPDK compilation is based on _target_, I really don't see any issue with this approach nor it does not hurt anything on server target. So, IMO, It should be upto the target to decide what works better for the target. Jerin > From my point of view NOOP on the driver level is more than enough. > Again I would prefer to introduce new config option, if possible. > > Konstantin > > > > > > >