From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7B342A0032; Sun, 17 Jul 2022 14:38:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0C26040695; Sun, 17 Jul 2022 14:38:09 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 8F91040687 for ; Sun, 17 Jul 2022 14:38:07 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 373365C0096; Sun, 17 Jul 2022 08:38:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 17 Jul 2022 08:38:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1658061486; x= 1658147886; bh=u+gWOFOEs8HbYP3c54gjzp5gVCtnIGuQOa11+e4Tri4=; b=0 JiR5ao9cCUJ0vtnE0GXwMtEcx7Au9kkzX0O5l55xpGMRfwO5yD5rvwmz4EEsheH/ dHY6D1UC2zfodIeNbVkHiG0zwczGWOdM8kjCrCcTN8Vbqn2OEBCliPDrVYkjXFl+ Agjjd6PjHl38/V0aUWnvRYjiN3MRh566Cokfpq5vn1Juqf/LnDquLK+cihX46b/j OB4Dx6qfpiYCZSf1wCefWCm3g0AkI3QZdrVs8gIkQ9Imx7QkLRfW7Ku+me27IHC5 zFiMhS+pstwgWK3+sCmfCi3KtndfzfmxNo5uXhiyy1y/x5B5+h0JyUsSgLaobkGD U7MQ7vpmSEs+YuvXe4E6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1658061486; x= 1658147886; bh=u+gWOFOEs8HbYP3c54gjzp5gVCtnIGuQOa11+e4Tri4=; b=T 7hiq9XeFnQdt+wpiJOsbSWRjAmFrji8Dc4To6K95cviKEa0p46ftRt9J/GuOYTic 6WvoeguDQOyLrOCkBJWOKHTh9UR0Cy7NCFDqG78DAKQU6PyqezoGjgVmgQDvGnv3 Y3MGINg6t8L92Q1Kx5ysPNZd2gLPWBDcR75T/vWzVDeHpIcREox0UpvX2qtXQjcb 31kGGKdlA2DTIv8epieS+s92ww5kqhisz7m7xHEptVeoJdxZ/Adk5NrA+au3BPgr PW84gLcWac8F226o8WabtZn3Qr0WGVv08R+XI9SfCRx13fAr8NZburbd+tSR9HKx o2AGktG3aRd7o9UCyvxHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudekiedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 17 Jul 2022 08:38:04 -0400 (EDT) From: Thomas Monjalon To: Pavan Nikhilesh Bhagavatula , "Van Haaren, Harry" Cc: "mattias. ronnblom" , dev@dpdk.org, Jerin Jacob Kollanukkaran , Ray Kinsella , "dev@dpdk.org" , "McDaniel, Timothy" , Hemant Agrawal , "sachin.saxena@oss.nxp.com" , "liangma@liangbit.com" , "Mccarthy, Peter" , "Carrillo, Erik G" , "Gujjar, Abhinandan S" , "Jayatheerthan, Jay" , "Burakov, Anatoly" Subject: Re: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event type Date: Sun, 17 Jul 2022 14:38:02 +0200 Message-ID: <1754321.3VsfAaAtOV@thomas> In-Reply-To: References: <20220627095702.8047-1-pbhagavatula@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 14/07/2022 18:57, Van Haaren, Harry: > > -----Original Message----- > > From: Van Haaren, Harry > > Sent: Thursday, July 14, 2022 5:54 PM > > To: Pavan Nikhilesh Bhagavatula ; mattias.ronnblom > > ; Thomas Monjalon > > Cc: Jerin Jacob Kollanukkaran ; Ray Kinsella ; > > dev@dpdk.org; McDaniel, Timothy ; Hemant > > Agrawal ; sachin.saxena@oss.nxp.com; > > liangma@liangbit.com; Mccarthy, Peter ; Carrillo, Erik > > G ; Gujjar, Abhinandan S > > ; Jayatheerthan, Jay ; > > Burakov, Anatoly > > Subject: RE: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event type > > > > > -----Original Message----- > > > From: Pavan Nikhilesh Bhagavatula > > > Sent: Thursday, July 14, 2022 5:42 PM > > > To: mattias.ronnblom ; Thomas Monjalon > > > > > > Cc: Jerin Jacob Kollanukkaran ; Ray Kinsella > > ; > > > dev@dpdk.org; McDaniel, Timothy ; Hemant > > > Agrawal ; sachin.saxena@oss.nxp.com; > > > liangma@liangbit.com; Mccarthy, Peter ; Van > > Haaren, > > > Harry ; Carrillo, Erik G ; > > > Gujjar, Abhinandan S ; Jayatheerthan, Jay > > > ; Burakov, Anatoly > > > Subject: RE: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event type > > > > > > > > > > >> If the underlying hardware has some limitations, > > > > >> why not let the driver loop until back pressure occurs? Then you can > > > > > > > > You didn't answer this question. Why not let the driver loop, until you > > > > for some reason or the other can't accept more events? > > > > > > CNXK event driver cannot accept forwarding(enq) more than one event that has > > > been dequeued. Enqueueing more than one event for forwarding/releasing > > > is a violation from HW perspective, this is currently announced by BURST > > capability. > > > But It can enqueue a burst if new events. > > > > Can't the driver just backpressure NEW events? that's what the event/sw driver > > does in order to limit "new" inflight events. App attempts to enq FWD/REL, no > > problem. App enqueues burst of NEW (and there's only N spaces) then the > > first N events pass, and the rest are returned to the application. > > > > > If you see the current example implementation we pick the worker based on > > > BURST capability for optimizing the enqueue/dequeue by providing a hint > > > to the driver layer. > > > > Please provide a link to the code? Others are not familiar with the CNXK driver, > > or the sample code you're referring to... > > > > > > > Although, we could live with aggregating the events at driver layer based on > > > queue. We would still require announce burst capability for new events i.e. > > > changes to the info structure. > > > > As per above, I still don't see a reason why this HW optimization/limitation > > needs to be pushed to the application layer. Why can the driver not handle > > things by allowing/backpressure to the events it can/can't handle? > > > > > > In this email thread[1] you've suggested reworking the rx_burst API with a > > flag to indicate "same destination". This still pushes the problem to the application, > > and exposes more HW/PMD specific options. This impl is *slightly* better because it > > wont' require new APIs for each mode, but also *breaks all existing apps*!? > > > > I'm just not understanding why the application needs to change, and why it > > cannot be optimized/handled in the driver layer. > > > > [1] http://mails.dpdk.org/archives/dev/2022-July/246717.html > > > > > > > Let me be very clear, but also try to help here; > I'm not in favour of the changes as proposed here, and feel that pushing > the problem to Application API is NOT the right solution. > > But *just in case* there is a *genuine* reason that we need an API/ABI > change, and that can be justified clearly in the upcoming weeks, then I'd > prefer not have problems with the deprecation notice not being included. > > This Ack is *only* to allow possible API/ABI changes in 22.11, and not for > the proposal above. > > Acked-by: Harry van Haaren It doesn't make sense to add a deprecation notice if the direction is not agreed. Let's discuss further and ask for techboard help if needed. In general, I would not be surprised that it's time for a cleanup in this API.