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 51C1C41CE4; Mon, 20 Feb 2023 00:30:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30FFE42D81; Mon, 20 Feb 2023 00:30:36 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id A7DB740691 for ; Mon, 20 Feb 2023 00:30:35 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4809A5C00A8; Sun, 19 Feb 2023 18:30:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 19 Feb 2023 18:30:35 -0500 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=fm1; t=1676849435; x= 1676935835; bh=M17PkDqNAcYCoeMhtqxWCVR/+afgS36hoF4evtMAAy4=; b=V OBgHSi/kc7xxSU8A5u+CWTJx7dWylyn6+VtghkWF0b/BV8gDjyFsezL/gSuah3j1 GCRJeeRbB0aBu9EBqvVQDgqoprPg6DiCSdcLfEgDtqfmo7jghAlmku6enOXcU+re yln585EVUHc/MM8RG/xyDKQCJTZHCqAbHFWskYgsB97dcx14fllBxKexJjRuwpFj YAtSgGvzmtwvaO3er03dv0EfxnPtUtH1w7sbw9DcSIf9CQota0WvbmN/1cRp6qu5 LRdceTed7HxKBtR7ZkY5dJVOuv+9UNhZFHBYuVzidR5/GZEuk6K8kiIABEz7p2iT FDBgffaNPvqEDK2eoVzhw== 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=fm1; t=1676849435; x= 1676935835; bh=M17PkDqNAcYCoeMhtqxWCVR/+afgS36hoF4evtMAAy4=; b=S Z1yVilkcLUdz5p43xvpK1L/SZ1XwI2ahajYqrlNGgRGl6XJ/GS6oCsa/T6botAA5 QTh6bEfpXFgshavagIPixBPhjUUiH/KzZxQfHjitZLco3fHhrgUXDfJ/lw7V7xVw A1WRtE0Hvf8Ar6FTpLYN2XhsJIez50WuW7cJ7e7NUUmKQlUJKME4YZgFBFICP7jP spPHWBBT66HnHZy0m5vVqOs8w9Ri0RcVV3qC9A5gC9mzoQ5CJPnyiv2kPD0H9n5f zvScVp/1SUla1RphUw4lDHQguCmdIKezOG888dLk6hQ8hPe+BtcBQLaZY+vy2e5W lit0zVU7Rj7YEAqhv465g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejgedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Feb 2023 18:30:34 -0500 (EST) From: Thomas Monjalon To: Volodymyr Fialko Cc: dev@dpdk.org, Reshma Pattan , jerinj@marvell.com, anoobj@marvell.com Subject: Re: [PATCH 1/3] reorder: add new drain up to seq number API Date: Mon, 20 Feb 2023 00:30:33 +0100 Message-ID: <2975061.WAvfycf1tz@thomas> In-Reply-To: <20230120102146.4035460-2-vfialko@marvell.com> References: <20230120102146.4035460-1-vfialko@marvell.com> <20230120102146.4035460-2-vfialko@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 We are waiting for a detailed review. The series could be merged without review. Please fix cosmetic comments below and send a new version to check CI result. 20/01/2023 11:21, Volodymyr Fialko: > Introduce new reorder drain API: > `rte_reorder_drain_up_to_seqn` - exhaustively drain all inserted mbufs > up to the given sequence number. > > Currently there's no ability to force the drain from reorder buffer, > i.e. only consecutive ordered or ready packets could be drained. > New function would give user ability to drain inserted packets, without > need to wait for missing or newer packets. > > Signed-off-by: Volodymyr Fialko [...] > --- a/lib/reorder/rte_reorder.h > +++ b/lib/reorder/rte_reorder.h > @@ -167,6 +167,31 @@ unsigned int > rte_reorder_drain(struct rte_reorder_buffer *b, struct rte_mbuf **mbufs, > unsigned max_mbufs); > > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice > + * > + * Fetch set of reordered packets up to specified sequence number (exclusive) > + * > + * Returns a set of in-order packets from the reorder buffer structure. > + * Gaps may be present since reorder buffer will try to fetch all possible packets up to given > + * sequence number. > + * > + * @param b > + * Reorder buffer instance from which packets are to be drained. > + * @param mbufs > + * Array of mbufs where reordered packets will be inserted from reorder buffer. > + * @param max_mbufs > + * The number of elements in the mbufs array. > + * @param seqn > + * Sequence number up to which buffer will be drained. > + * @return > + * Number of mbuf pointers written to mbufs. 0 <= N < max_mbufs. > + */ > +__rte_experimental > +unsigned int > +rte_reorder_drain_up_to_seqn(struct rte_reorder_buffer *b, struct rte_mbuf **mbufs, > + unsigned int max_mbufs, rte_reorder_seqn_t seqn); > #ifdef __cplusplus blank line missing > --- a/lib/reorder/version.map > +++ b/lib/reorder/version.map > @@ -16,4 +16,5 @@ EXPERIMENTAL { > global: > > rte_reorder_seqn_dynfield_offset; > + rte_reorder_drain_up_to_seqn; Please add a comment "# added in 23.03" as we do in other libs.