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 373B3A0577; Mon, 6 Apr 2020 16:00:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A807A2B86; Mon, 6 Apr 2020 16:00:18 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 05D7C2B83 for ; Mon, 6 Apr 2020 16:00:17 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 9CFE25801F9; Mon, 6 Apr 2020 10:00:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 06 Apr 2020 10:00:16 -0400 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=jO3GkFhp6LyT9ckEgiQLtNOusgd6NHYmBOh19/0MA+8=; b=Swrq3f2JlbpK Z6/tWHEtjEQUMQSBGyB9l+AhSppop5YnIv3n9T3n5ipvSBMx4C5YAfotPTJ+hGtp gLIxBb7HoBeJa1KNBq4SVF3/KhXDJzS34J5wwzBWOEOWg3McrXu+f2me4JfJbVV5 HBTPMzhisMswZ1fcZwj9WLn0loZEDIk= 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=fm2; bh=jO3GkFhp6LyT9ckEgiQLtNOusgd6NHYmBOh19/0MA +8=; b=gVdK9lSFF40QJjw7scwGrIY9ziC+6PN29gu1zZ0W+lUK7doATA7xamnST 07m8unjQATiiqdR73RYQywHG7yBjPEwPyU4ql+FFt8QGRhkjy7nRvwJiiU8ER1tE JZPxMiHw9bjP1dFXGRl8tJoZqgmQeil2Bh2p5RqXflzwmBqzk/mrjt/NAk2KdcEO wEmrlIRqDcv/H0X2GCMagha91h+GaeNI84WgPdiI6e6q6QyHYMkXAC1Rn0qgeiUy /sIpuKtqQYoy9mjJAJWVjPsRRwTLJFfEcYJZ/rhrqpba0gKVtw3kWzxZAPEq+wfd gcpTatjF7/5HCXjuPnak7J3rNkbxg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepphhrohhofhhpohhinhhtrdgtohhmpdhmrghilhdqvdgurghrtghhihhvvgdr tghomhdpgedtughpughkrdhorhhgpdguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F55C306D445; Mon, 6 Apr 2020 10:00:06 -0400 (EDT) From: Thomas Monjalon To: Pavan Nikhilesh Bhagavatula , Ori Kam Cc: Jerin Jacob Kollanukkaran , "xiang.w.wang@intel.com" , "dev@dpdk.org" , Shahaf Shuler , "hemant.agrawal@nxp.com" , Opher Reviv , Alex Rosenbaum , Dovrat Zifroni , Prasun Kapoor , "nipun.gupta@nxp.com" , "bruce.richardson@intel.com" , "yang.a.hong@intel.com" , "harry.chang@intel.com" , "gu.jian1@zte.com.cn" , "shanjiangh@chinatelecom.cn" , "zhangy.yun@chinatelecom.cn" , "lixingfu@huachentel.com" , "wushuai@inspur.com" , "yuyingxia@yxlink.com" , "fanchenggang@sunyainfo.com" , "davidfgao@tencent.com" , "liuzhong1@chinaunicom.cn" , "zhaoyong11@huawei.com" , "oc@yunify.com" , "jim@netgate.com" , "hongjun.ni@intel.com" , "j.bromhead@titan-ic.com" , "deri@ntop.org" , "fc@napatech.com" , "arthur.su@lionic.com" , "david.marchand@redhat.com" Date: Mon, 06 Apr 2020 16:00:04 +0200 Message-ID: <9615243.0lO9i7VF8o@xps> In-Reply-To: References: <1585464438-111285-1-git-send-email-orika@mellanox.com> <1620573.TTEOE9XjLl@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions 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" 06/04/2020 15:50, Pavan Nikhilesh Bhagavatula: > From: Thomas Monjalon > >> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula: > >> >> >> From: Pavan Nikhilesh Bhagavatula > >> >> >> > >+uint16_t > >> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t > >> >qp_id, > >> >> >> > >+ struct rte_regex_ops **ops, uint16_t > >> >nb_ops) > >> >> >> > >+{ > >> >> >> > >+ return regex_devices[dev_id]- > >> >> >> > >>enqueue(regex_devices[dev_id], qp_id, > >> >> >> > >+ ops, nb_ops); > >> >> >> > >+} > >> >> >> > > >> >> >> > Move these functions to .h in-lining them. > >> >> >> > Also, please add debug checks @see > >> >> >rte_eth_rx_burst/rte_eth_tx_burst. > >> >> >> > >> >> >> O.K will update. > >> >> > > >> >> >In general, inlining is a pain for ABI compatibility. > >> >> >Please inline only if the gain is very significant. > >> >> > > >> >> > >> >> The performance gain mostly comes from hoisting > >> >`regex_devices[dev_id]` load above the > >> >> poll loop. > >> >> Since, the performance measurement application is still in pipeline > >> >and regexdev would be > >> >> experimental for next couple of releases I suggest inlining it now > >and > >> >worrying about ABI when > >> >> experimental tag needs to be removed. > >> > > >> >No, we must worry about ABI from the beginning. > >> > >> I though performance was the primary objective :-). > > > >It is. > > > >> >> We can follow the same path as done by ethdev > >> >[https://urldefense.proofpoint.com/v2/url?u=https- > >3A__www.mail- > >> >2Darchive.com_dev- > >> > >>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xt > >f > >> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o- > >> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd- > >> > >>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e > >= > >> >] > >> > > >> >ethdev is not an argument. > >> > >> What about ring? [https://urldefense.proofpoint.com/v2/url?u=http- > >3A__mails.dpdk.org_archives_dev_2020- > >2DApril_161506.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3S > >gYMjtKCMVsB-fmvgGV3o- > >g_fjLhk5Pupi9ijohpc&m=u9gnM_YrOJDusN4yR8YUcUuUkri4tOjnHrQ0A > >Qd5zTw&s=uv6AQA- > >Zu7o6ugyhpGHLxFOk4SfEdkHfFGDmhzANRME&e= ] > >> > >> Why do we need to prove the same performance advantage using in- > >lining for datapath > >> critical functions again and again? > > > >Because every libraries have not the same usage and load. > >We should compare how much cycle is saved with inline vs > >how much cycles is, "in average", a regex burst? > > > >If you tell me regex processing is fast, OK, let's inline. > > > > Regex processing speed would still be dependent on underlying device capabilities. > > All we are trying to do is reduce the enqueue/dequeue completion time which would > bring down the overall latency. Take your regex HW and do a simple regex processing burst. How many cycles it takes to complete? How many cycles you lose if not inline? If the ratio is lower than 1/200, I think inline is not a must. Ori, please consider the same measure for your HW.