From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <konstantin.ananyev@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 6BED837B2 for <dev@dpdk.org>; Wed, 9 Mar 2016 17:18:14 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 09 Mar 2016 08:17:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,311,1455004800"; d="scan'208";a="933130397" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga002.fm.intel.com with ESMTP; 09 Mar 2016 08:17:21 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.35]) by IRSMSX109.ger.corp.intel.com ([169.254.13.174]) with mapi id 14.03.0248.002; Wed, 9 Mar 2016 16:17:20 +0000 From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> To: Thomas Monjalon <thomas.monjalon@6wind.com> Thread-Topic: [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Thread-Index: AQHRbyZIC6RAW0jzIEeJRoaRUBOzep9QO/iAgADx3hCAABMIAIAABTJggAALvwCAAAIm8IAABQ8AgAACluA= Date: Wed, 9 Mar 2016 16:17:19 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B1A6C4@irsmsx105.ger.corp.intel.com> References: <1452869038-9140-1-git-send-email-tomaszx.kulasek@intel.com> <5916803.8PiAMBcxJt@xps13> <2601191342CEEE43887BDE71AB97725836B1A669@irsmsx105.ger.corp.intel.com> <2507362.eR3Lu18VyN@xps13> In-Reply-To: <2507362.eR3Lu18VyN@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTJmNmY4NDItNjNiMy00ZTVkLWJlNzEtMTk3MjBhYTI3NjhhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik9mY0N1dXJlMjlIRndIRVMrdFlESXIrelJTT3JYaDlvbmhlRHZcL1k2NW80PSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 09 Mar 2016 16:18:15 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, March 09, 2016 3:52 PM > To: Ananyev, Konstantin > Cc: Kulasek, TomaszX; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api >=20 > 2016-03-09 15:42, Ananyev, Konstantin: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-03-09 15:23, Ananyev, Konstantin: > > > > > > > > > > 2016-03-09 13:36, Ananyev, Konstantin: > > > > > > > > + if (to_send =3D=3D 0) > > > > > > > > + return 0; > > > > > > > > > > > > > > Why this check is done in the lib? > > > > > > > What is the performance gain if we are idle? > > > > > > > It can be done outside if needed. > > > > > > > > > > > > Yes, that could be done outside, but if user has to do it anywa= y, > > > > > > why not to put it inside? > > > > > > I don't expect any performance gain/loss because of that - > > > > > > just seems a bit more convenient to the user. > > > > > > > > > > It is handling an idle case so there is no gain obviously. > > > > > But the condition branching is surely a loss. > > > > > > > > I suppose that condition should always be checked: > > > > either in user code prior to function call or inside the > > > > function call itself. > > > > So don't expect any difference in performance here... > > > > Do you have any particular example when you think it would? > > > > Or are you talking about rte_eth_tx_buffer() calling > > > > rte_eth_tx_buffer_flush() internally? > > > > For that one - both are flush is 'static inline' , so I expect > > > > compiler be smart enough to remove this redundant check. > > > > > > > > > So why the user would you like to do this check? > > > > Just for user convenience - to save him doing that manually. > > > > > > Probably I've missed something. If we remove this check, the function > > > will do nothing, right? How is it changing the behaviour? > > > > If we'll remove that check, then > > rte_eth_tx_burst(...,nb_pkts=3D0)->(*dev->tx_pkt_burst)(...,nb_pkts=3D0= ) > > will be called. > > So in that case it might be even slower, as we'll have to do a proper c= all. >=20 > If there is no packet, we have time to do a useless call. One lcore can do TX for several queues/ports. Let say we have N queues to handle, but right now traffic is going only thr= ough one of them.=20 That means we'll have to do N-1 useless calls and reduce number of cycles available to send actual traffic. >=20 > > Of course user can avoid it by: > > > > If(tx_buffer->nb_pkts !=3D 0) > > rte_eth_tx_buffer_flush(port, queue, tx_buffer); > > > > But as I said what for to force user to do that? > > Why not to make this check inside the function? >=20 > Because it may be slower when there are some packets > and will "accelerate" only the no-packet case. >=20 > We do not progress in this discussion. > It is not a big deal,=20 Exactly. >just a non sense. Look at what most of current DPDK examples do: they do check manually does nb_pkts=3D=3D0 or not, if not call tx_burst(). For me it makes sense to move that check into the library function - so each and every caller doesn't have to do it manually. > So I agree to keep it if we change the website to announce that DPDK > accelerates the idle processing ;) That's fine by me, but at first I suppose you'll have to provide some data showing that this approach slowdowns things, right? :) Konstantin