From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 98179A04AB; Mon, 11 Nov 2019 18:30:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DCF4DDE3; Mon, 11 Nov 2019 18:30:35 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 701B0CF3 for ; Mon, 11 Nov 2019 18:30:34 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AAE0A487; Mon, 11 Nov 2019 12:30:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 11 Nov 2019 12:30:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=6hE++F4nwDoJ9nGt3zLmh30kLKjC9DRHaEY4+tjzub0=; b=lMTFNQc+o9gx 8Vy+INNi1H8cHdn2Wmyi1JnoFVhb8x6QUoHdKst9f1IXAot/VG08ds7tzD3b4NvE 8PMzCMrM1czJwzNHYTr69fBa7ZSMu7FRlFRswf8GV6zO29AQpyLumVm9WvAuq/GH cV3MbpbbA+BwWqrH7GismMJkPPuhkoU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6hE++F4nwDoJ9nGt3zLmh30kLKjC9DRHaEY4+tjzu b0=; b=UO1LHT40MRuT3YWgaqrCcMQiEkmwYcNFr6/acZ6Bs0pfOnElqdlfGS+m1 UO1coXnpCYhM5cxUMRYEOdMlBhwOrJ1kYYVhh3wRxMD6L5mLbDzk0wJ5lV1gZ7PM JntXmzL6UmRcIo8IH9349qwWvSMzHR+n7orH9rFucjYIDvAptJcfxDX4Dpfz/+Yt EPq7+2u0BJn6aPddUpFbyoJqOvUebCDwWcwadvS1mRBeSwsLvYr1VaW+BzwlKuy5 l9J864EhufJi2Vmv+iKB60jrHTjN33vBpoGDa7iSrLqvnH9SckPLCSSGnES9COiw oVG9Ou/u0nrmJRA3ms8G+4LxqMGdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvjedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepfeejrddujeefrddvheegrdegjeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (unknown [37.173.254.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 22AF480064; Mon, 11 Nov 2019 12:30:18 -0500 (EST) From: Thomas Monjalon To: dev@dpdk.org Cc: Ferruh Yigit , "Yigit, Ferruh" , Nilanjan Sarkar , Andrew Rybchenko , Konstantin Ananyev , Bruce Richardson , "Kinsella, Ray" , Olivier MATZ , Jerin Jacob Date: Mon, 11 Nov 2019 18:30:12 +0100 Message-ID: <4483786.soQ6Bse14g@xps> In-Reply-To: <2e01890d-c21e-a7de-8674-eb2ab139aa2d@intel.com> References: <20190808122819.6015-1-nsarkar@sandvine.com> <2e01890d-c21e-a7de-8674-eb2ab139aa2d@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: added new api to only enqueue a packet in tx buffer 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 11/11/2019 17:56, Ferruh Yigit: > On 10/18/2019 5:24 PM, Yigit, Ferruh wrote: > > On 8/8/2019 1:28 PM, Nilanjan Sarkar wrote: > >> This api is similar like api `rte_eth_tx_buffer` except it > >> does not attempt to flush the buffer in case buffer is full. > >> The advantage is that, this api does not need port id and > >> queue id. In case port id and queue id are shared within threads > >> then application can not buffer a packet until it gets access > >> to port and queue. So this function segregate buffering > >> job from flushing job and thus removes dependency on port and queue. > > > > Hi Nilanjan, > > > > Sorry, the patch seems missed because of the misleading module info in the patch > > title, this is not an 'eal' patch but a 'ethdev' patch ... > > > > Related to the API, it looks like target is to reduce the critical section which > > looks reasonable to me. > > > > A concern is related to the making this function inline, we are discussing > > moving existing inline functions to regular functions, this may have performance > > affect but if the drop is acceptable what about making this an ethdev API? > > > > There was no response on making the new proposed API a proper function. > > @Thomas, @Andrew, et al, > > What do you think about a new static inline ethdev API? > > >> +static __rte_always_inline int > >> +rte_eth_tx_enqueue(struct rte_eth_dev_tx_buffer *buffer, struct rte_mbuf *tx_pkt) > >> +{ > >> + if (buffer->length < buffer->size) { > >> + buffer->pkts[buffer->length++] = tx_pkt; > >> + return 0; > >> + } > >> + > >> + return -1; > >> +} It looks reasonnable. But the function name should include _buffer_ What about rte_eth_tx_buffer_enqueue?