From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6339629B6 for ; Wed, 9 Mar 2016 16:24:56 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 09 Mar 2016 07:23:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,311,1455004800"; d="scan'208";a="760989126" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 09 Mar 2016 07:23:52 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.35]) by IRSMSX102.ger.corp.intel.com ([169.254.2.19]) with mapi id 14.03.0248.002; Wed, 9 Mar 2016 15:23:51 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Thread-Index: AQHRbyZIC6RAW0jzIEeJRoaRUBOzep9QO/iAgADx3hCAABMIAIAABTJg Date: Wed, 9 Mar 2016 15:23:50 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B1A627@irsmsx105.ger.corp.intel.com> References: <1452869038-9140-1-git-send-email-tomaszx.kulasek@intel.com> <4446137.g0qt5Fe5Df@xps13> <2601191342CEEE43887BDE71AB97725836B1A4A2@irsmsx105.ger.corp.intel.com> <1964417.t7N6HDkJH0@xps13> In-Reply-To: <1964417.t7N6HDkJH0@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzNhMDgzN2ItNWIyZi00ZDYwLWEzMGQtNGJkYzRkYjU0MDUwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkoxQjR6T0JBN2gwd3BoT3NTQ2lmajlWeEVvUVhHV1c2WlJvSGxaTk9ISW89In0= 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:24:56 -0000 >=20 > 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 anyway, > > 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. >=20 > 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?=20 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. =20 > So why the user would you like to do this check? Just for user convenience - to save him doing that manually. Konstantin