From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0056.outbound.protection.outlook.com [104.47.34.56]) by dpdk.org (Postfix) with ESMTP id 1D3E71396 for ; Tue, 12 Sep 2017 06:01:33 +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=P6vZvtxDBPnwYi5sj/W5eBJSIjrpnzxCmWk77MmnQnY=; b=kqn4tIfdEWJxk2GiDREzol4aORrmZ0xAWWiXgjripxVdliFAbDMygzAB9xGBjVdl93VmRbkWXJzPcwex1AEYNU9UGF3R1chi42EeExdobOLsG+CX+xwDG9NpE0QvjNdH/0mkQZy7QwBO4lawAQz/p44psb3iL3FVTVJ5T86F7J0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (14.140.2.178) by BN3PR07MB2513.namprd07.prod.outlook.com (10.167.4.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 12 Sep 2017 04:01:26 +0000 Date: Tue, 12 Sep 2017 09:31:09 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: Shahaf Shuler , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" Message-ID: <20170912040107.GA8081@jerin> References: <20170910104827.11da9230@xeon-e3> <20170911062119.GA9342@jerin> <20170911080621.GA15867@jerin> <20170911090543.GA9965@jerin> <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: BM1PR01CA0109.INDPRD01.PROD.OUTLOOK.COM (10.174.208.25) To BN3PR07MB2513.namprd07.prod.outlook.com (10.167.4.138) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: efc21520-f832-4abf-f6e0-08d4f992f2a5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 3:ZMq/kTRdK/HF6uL22DEp319S+gJBQZhZTGGNlZkx2zJwFPdDu82ich8eGZDC2nUM9VoV5cK0Cho6LID31qru50uBdedRfQCT2xVeccmagqiGHMnrOjQDGS+3/O9h70jkY9Sb/qJZv0WSyDYbiRJTLYNRFrIter/F8Kc/QZkWGfCcmOj+nvWQmGSPmWgr7TFdycDkw45AAkPg6QQ2yRoDb7kSuDl1E2o5ulrLUMQbRD7q28FEiPXvGFUdie76/oUF; 25:JMf2v2oWWBvsGqTl06pYwMd4/4fMv/PDmtMD1Lg7+L6FxUghhOiIIur5h2dyhpHzLNLFbrfwto64U3NQN/cZD9s/i9rJ/OPvdeXjf3OFBPfZAG1CumQ48kJ/TPpRmV3g8f2hXrFlx8q6mRA8qdy4OF/gIOOouU32A3ntQgFi+fKn9Jc/JwBJcgSccKgOXP4kN5eHMdm/W5ctiXVVfOdUlilmZr1VqbOlYLDbdP8diTv+DacrtzQuat/PIUtRe52KW4sX122ufVTsEZ1X6Q2VZImsLhnM0mWpZd8ThKcouTmEuwhlUdHdCqT4FrroevhMbvWUd+TnpC+6HW6ZU9JmIw==; 31:0VwHGxGlGbJoTs9Z7w8ntir3c6wlz+A9DbnGJaEJJU30nS5ChzTe+Zj2Uczf37vcTvAXxlfEjD40wjgA8r1+jJqxt/P3rlSkw3fYh4IswdJ2KUCrCOztkERYfVnAlQ9U7ZQsiQybEpR020ci1g479T4APQkyS8DCX5uqdKrYYCqE0ccB8W1leQHj6hAVxnF+15N9VPIGYq7cuz7rHYKjTYKIyrxMZRW4fS+Nhy8uSbE= X-MS-TrafficTypeDiagnostic: BN3PR07MB2513: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 20:RPBfxB4UE960VcnxNb3tMuv9V4HgivnSTFG3E1HNtU6/HXl/lptnTtu3fFZAjzId8DIQUfwYb5Dja9QMCdO/ks45ZzRaKRLmYH7ZUpiO+V4lA/L3/kT9WM0Ve64gXc4fA3B0Ah0yAc5vMg9M+vnbHgQuGmywXoNZ0VvitZ26YXtSbAawMuCtUfWYCcI+6INcCqd0sI+8yMTLSkFlStcd/5k7nNMVOzK0f6vtk7r5Q4XAZjWaLt6T3F6dPSN3ebfG7u5lnGiZ7ctF3nX05Cdz0PuWjmUgoYd3hQ63qUC7QEIbvuL24SUdFWc8a5mhIhdho+MV9khJOXrj6x7u/zEdYZH7KofiveLjPR6TkIFmTUcPtn6K1tz0OQrIFVNBoZIkaQ1Q45V4lZlbsXCfZpyYXx4CBJ5f36IFrr00zitsa+Ac3zs8wYDObc10i5yIKLyjPBM9kynq9YmeBDSOmE1bnX6ShEz7Xa1Fnwh6rXn/JdX4r35XtSUM3NIPbByHBmbyxN4evlbjSxmRT1uBkor4oJdqgkb0YJJDc3fsnBruDAKbHjtJ2hOCq/SsOzpkDrA1psFX29srC+PNBS03mW+j8C8SpLG0VxeRwiBSnhvSIHA= X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR07MB2513; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 4:AJa6wIK7mAcI5SJuXzIKY4SnVsSy+UtrV8vgK8aiB93CX9Paq3B+IMoave79tQ38i9QGAWEtBNxI9sTrHFsL+QoF3EvpHwiwZvfCttPWc28UAbiVWkIT1R6jYGtgwEyZwV6wyhcP508blm8v1bRD6dN+A5fciwNXhbZWNrCJjBSQzaFXkb+f50Ean7RSXubv1hDuk846dcMRc77rXZ0zeXGQlEBcCHEWiuUG0//MKxmLuqcZKgKEHRQz0G7m4+EiwVVh/wN1ElIpouYbhCvCmT9E0CxekhVZdT82Kuenx4hx1G+c+wzD1wmFkkFY5Ua/dPf2cohGE62S1Vi9rFPQEg== X-Forefront-PRVS: 042857DBB5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(52054003)(189002)(13464003)(43544003)(199003)(3846002)(66066001)(50466002)(33656002)(53936002)(105586002)(54356999)(9686003)(4001350100001)(55016002)(54906002)(50986999)(76176999)(189998001)(478600001)(68736007)(5660300001)(33716001)(47776003)(6116002)(6916009)(6666003)(42882006)(106356001)(4326008)(8936002)(229853002)(2906002)(101416001)(2950100002)(6496005)(110136004)(42186005)(305945005)(25786009)(6246003)(5009440100003)(8676002)(83506001)(1076002)(81166006)(23726003)(81156014)(93886005)(97736004)(72206003)(7736002)(316002)(110426004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2513; H:jerin; 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; BN3PR07MB2513; 23:sTodx/ke+r7UZ2z4DkYjyZ93eiJ5gvxnU3NSk3hft?= =?us-ascii?Q?3plQEyrE/RLzlDM2rwVJH9+5g2NP7VFTCJiOHfP7RTX/fDvvpIppnQev3VRx?= =?us-ascii?Q?ecZcVKKqtXig+JKBLV8gMLbsu6DF2GBC8LAaJJT8dyJS0T1zhMP2XeeQBh8I?= =?us-ascii?Q?HY8nDfa9D4wTnVwclkL0UEnS97gjcaUb4WSUsFY628jDR0QJC1YvmF0KqGiZ?= =?us-ascii?Q?7jxnx0OSxNh/Tx3qynoO0hNwFy+aK73/8TIDUT5SW0eP4N+IQbYGVna0uJRN?= =?us-ascii?Q?+jSbWox0bnSn15sTJwqJqyeu64yNwq7Vdar2hPTnWumRlyTHGP9DIFNHdIDv?= =?us-ascii?Q?JYLv9C10Fml2U3vYi8qt9uOxECXmvEPMGFGUCKZHzbPM22l7ycWs0/p6YBdx?= =?us-ascii?Q?sd9xr4uYBbSe6Z+f6UvPiKAOfw0nJa1/n3y+Pix9v9h3qd5UuaiBvO2bybiO?= =?us-ascii?Q?2YctSfhev8y/J6pQTpdAPCQhMYDMhC9Cg5ivzuR+MsajZChgmnr4gtCh6ite?= =?us-ascii?Q?pDJ0GhX/AJYBzfdj8GRiHMNzHzO2JrFKt/qV2bRZ2f3ZESvPvDTD69nUjl5H?= =?us-ascii?Q?nyxzLdu7ZGbppJc3i7VP1HkGZZnTu8A6dgzCoNzhpUsykuLGrK+DW2xr1gKC?= =?us-ascii?Q?JpsxjN134YXA7zObeZGu2QzP+MwDpnJHvZZ23MWpsWD1vhMvBLLUuQV38dcx?= =?us-ascii?Q?x68/NjUoQGhgOrg2ZoJzf+D4mtpfoPkjENKPjICniheO5O81dbkNYjSMXZvg?= =?us-ascii?Q?A3N06bS/SWxA1OXSsuf6sKs6RhT/I3nEcCnPYdcCAhMGhZAnHM9q8CHW3D3C?= =?us-ascii?Q?FkrVJyX7Z7m4fXPN5gnlBx3/giNWJTV500FMSDd144asKcfGR0xNlYT7/ZF2?= =?us-ascii?Q?WJ3MYkR29kC5vo41Gqat4RvU8DKMEEJpsGeS7IId0v/Ul2455YO514e9VPKI?= =?us-ascii?Q?Xt7TeMu3e8GtRtNAZ2jeqnfEORn8IeQ0X1J5zZHDPBHFb7k1bN0Hi/1a1tZk?= =?us-ascii?Q?6NL8w6SHY3uT6yEHRDuZXkGU+aPnmeXqD+Q4gsGSHBFKBjIpAg+I0FRz+5c0?= =?us-ascii?Q?gLCVFiHcwsWy/EICvqpfVvZQ/CSqYJ3cMjd++49ki5EQbkTWq07A0sfRX6Ph?= =?us-ascii?Q?/rYbeoUtWUudb/POohHqBNUnq+YjWwtZGkwoy0q+k9t4eCbU88sdo/xMGf5Z?= =?us-ascii?Q?Xy9C4gP4hclJkfmK4U9Qcw/gKKPpi5O7t0UCK4qY+O5wxCwCzUvJc5q1dIDP?= =?us-ascii?Q?4PM43kJSjMHhsGT8AgfsFRROE1CK6DGxBAvxJxdQ7bBe4w9nbcCypmd4GGkr?= =?us-ascii?Q?9skXF/pnzPdFN0ApfCJyjb1LoA/8dTpoXcZ1XUIaDQR?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 6:LqwpBpug8sWunHGbGW/3SJGRsd0MZ9MOzmbhan5iGzZ1jFw8fvoSDN0PqjIvYoA8TqmuDkUnJmbC7Srrviyc5PdZZ0QAzc6akEG97LD20RMsvykub+yfpQp9mhhbiOcgJKpIlkSGG7FwLejnTZw/aJCBTv0jx2Axz0DH3cUfbwwROLaw9Od2BZrEmv8T2juv3ymak/Dp+iQyWjptcZMahL0BZE4OXXCFDLYsCSeGE6pjteFgu4f6Hg1aBm22qkLxKZfQ3cz68DDvulliZchbhNRRqpJroIktzamSIAn1EkUPl4tYOju6BS/X6hX9G0cfpC+QdpqvKF70hw1Q6TSbkg==; 5:9aknOLEP8urNFOhdugWl38/YeLYMbnRapGI9SsPE6235/LNXOugkqLvnzChNriAoHhu/nr9Pm+0BGQiA458IK4eeLJP2UOdvKUopWntcxfK7PJHvZOJ0QQeICXU5JcAReR9Bctf5lA9z7y8cv1eqtA==; 24:6J7Rcr2BTJmZQ/hRkDPTmVuUS+1kIehmXS+HL4Ijbp3io2L9B25QWj9bYO7HvJRzqgSQ4dadJ/pqEE6+b7PbLNLF/xnLkmv7QNXszi8VEgA=; 7:ID2sBfP71UgMFccoyN2d738cirHUMxsh/deMZdxmlcmqDWBG2GFkRvO7HGe9QukY/8G1FhuAbwYxKGldv3ADH34keWb7DXIKA7/9YON0xg0Kqc740w90ksr4v4tuB+eFBYe6Pq9IiAxOcbPOm5k9mNZTQUdGgD3FDMQ7Xdxz61We2wCVJ+ETnH/j+TRHYGjD3kdO4Lsn4JgCJefE94fTWJ8p14AZG2uijhkQGRtX6O8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2017 04:01:26.9617 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2513 Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API 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: Tue, 12 Sep 2017 04:01:33 -0000 -----Original Message----- > Date: Mon, 11 Sep 2017 11:02:07 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob , Shahaf Shuler > > CC: Stephen Hemminger , Thomas Monjalon > , "dev@dpdk.org" , "Zhang, Helin" > , "Wu, Jingjing" > Subject: RE: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads > API > > > > > > > > > > > > I don't understand. > > > > > From the exact link above, you explicitly say that *you* will move this flags > > > > once the series is integrated. Quoting: > > > > > > > > > > " > > > > > > Please Jerin, could you work on moving these settings in a new API? > > > > > > > > > > Sure. Once the generic code is in place. We are committed to fix the > > > > > PMDs by 18.02. > > > > > > > > Yes. I will take care of the PMD(nicvf) side of the changes. Not in ethdev or > > > > mempool. Meaning, you need to decide how you are going to expose the > > > > equivalent of these flags and enable the generic code for those flags in > > > > ethdev or mempool. The drivers side of changes I can take care. > > > > > > > > > > How about doing it a PMD option? > > > Seems like nicvf is the only PMD which care about them. > > > > Lets take flag by flag: > > ETH_TXQ_FLAGS_NOMULTMEMP - I think, this should be removed. But we can have > > common code in ethdev pmd to detect all pool being configured from on the same pool > > as on the rx_configure() application passes the mempool. > > > This is TX offloads, not RX. > At tx_queue_setup() user doesn't have to provide the mempool pointer, > and can pass mbuf from any mempool to the TX routine. > BTW, how do you know one which particular mempool to use? > Still read it from xmitted mbuf (At least first one), I presume? Yes. Still it reads from xmitted mbuf for the first one. > > > > > ETH_TXQ_FLAGS_NOREFCOUNT: This one has i40e and nicvf consumers. > > About i40e - as far as I know, no-one use i40e PMD with this flag. > As far as I remember, it was added purely for benchmarking purposes on some early stages. > So my vote would be to remove it from i40e. > Helin, Jingjing - what are your thoughts here. > About nicvf - as I can see it is used only in conjunction with ETH_TXQ_FLAGS_NOMULTMEMP, > never alone. > My understanding is that current meaning of these flags > is a promise for PMD that for that particular TX queue user would submit only mbufs that: > - all belong to the same mempool > - always would have refcount==1 > - would always be a direct ones (no indirect mbufs) Yes, only when ETH_TXQ_FLAGS_NOMULTMEMP and ETH_TXQ_FLAGS_NOREFCOUNT selected at tx queue configuration. > > So literally, yes it is not a TX HW offload, though I understand your intention to > have such possibility - it might help to save some cycles. It not a few cycles. We could see ~24% drop on per core(with 64B) with testpmd and l3fwd on some SoCs. It is not very specific to nicvf HW, The problem is with limited cache hierarchy in very low end arm64 machines. For TX buffer recycling case, it need to touch the mbuf again to find out the associated mempool to free. It is fine if application demands it but not all the application demands it. We have two category of arm64 machines, The high end machine where cache hierarchy similar x86 server machine. The low end ones with very limited cache resources. Unfortunately, we need to have the same binary on both machines. > Wonder would some new driver specific function would help in that case? > nicvf_txq_pool_setup(portid, queueid, struct rte_mempool *txpool, uint32_t flags); > or so? It is possible, but how do we make such change in testpmd, l3fwd or ipsec-gw in tree application which does need only NOMULTIMEMP & NOREFCOUNT. If there is concern about making it Tx queue level it is fine. We can move from queue level to port level or global level. IMO, Application should express in some form that it wants only NOMULTIMEMP & NOREFCOUNT and thats is the case for l3fwd and ipsec-gw > So the user can call it just before rte_eth_tx_queue_setup()? > Konstantin > > > And it is driven by the use case too. So it should available in some > > form. > > > > > > > > If there will be more PMDs later, we can think about which API is needed. > > >