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 B763CA0546; Tue, 6 Apr 2021 18:22:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D8A2140F37; Tue, 6 Apr 2021 18:22:38 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 57C29140F36 for ; Tue, 6 Apr 2021 18:22:37 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 887B15C009B; Tue, 6 Apr 2021 12:22:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 06 Apr 2021 12:22:36 -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=fm3; bh= i8FbEBsU6Eu3g83mbGiKvltaP0HxMdAgxjzG4rd9TRE=; b=XDZwy3bKINK0/b/u 8aBtD2DzuUisxokXBsPqiCh1a8FW/bVZZev8f2CooHS2mLVjq00ltNWRRxMo1pqu 9JHyAnRmr+iS4agKu0rhgffVAObFZX64GSu23U52y8gpkqgFWPuVHMqI2yJQkS2D zgAoQzYdRrzu3zCMtkFagTrHcg0kCRxvQpaQF3RTK1OVeAM3SqrHtEjfyGnVpHef exyly/Bat7Sq31XeK8TmjFlV0Uu+o8OyiRB8c03wXGKoJDJhfNURoao+60mfcf6G XlGnaq0qvno4qEiN8+B44UicpD2wrXHBZDSqWNryCOnO1LmO5TeDImxZt62uNR4U XXtEzQ== 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=i8FbEBsU6Eu3g83mbGiKvltaP0HxMdAgxjzG4rd9T RE=; b=CCIiiDHYrGttJ4GR71TpvCMP+jNm+1uUF27YoVPx7AWLu+JI0bCryS+Hq qCHs/ekmiC4nFQKnCd/irsPbJGr77k6gUjrvO9tBFTHctRRHzBVp04a6d4tEJ8PJ BIu+PQkBjFHdUUelwsEUmQPnXXz9v7JHzunLbZbo1PG/lDJwxNTrbj29NV48NOov Qbe9byiq+RirX3qXJfjTGxmh9zVWTXdwPMVOoyf5Z/4iG6HLLvKyEJd+uwSmWmTI lXQRLG+YHr7MMgNBTudKlFK9votAIY51jO/brPM0EQCBdiFWr/imYXmTrogekZNN 7TFvzRdCShtWDi2BrUJWgxajU+Umw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejhedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 4FE5F108005F; Tue, 6 Apr 2021 12:22:35 -0400 (EDT) From: Thomas Monjalon To: John Hurley , Suanming Mou Cc: orika@nvidia.com, dev@dpdk.org, viacheslavo@nvidia.com, matan@nvidia.com, rasland@nvidia.com Date: Tue, 06 Apr 2021 18:22:34 +0200 Message-ID: <1630409.ut38131ehT@thomas> In-Reply-To: <20210330013916.1319266-5-suanmingm@nvidia.com> References: <20210309235732.3952418-1-suanmingm@nvidia.com> <20210330013916.1319266-1-suanmingm@nvidia.com> <20210330013916.1319266-5-suanmingm@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 4/4] regex/mlx5: prevent wrong calculation of free sqs in umr mode 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 Sender: "dev" 30/03/2021 03:39, Suanming Mou: > From: John Hurley > > A recent change adds support for scattered mbuf and UMR support for regex. > Part of this commit makes the pi and ci counters of the regex_sq a quarter > of the length in non umr mode, effectively moving them from 16 bits to > 14. The new get_free method casts the difference in pi and ci to a 16 bit > value when calculating the free send queues, accounting for any wrapping > when pi has looped back to 0 but ci has not yet. However, the move to 14 > bits while still casting to 16 can now lead to corrupted, large values > returned. > > Modify the get_free function to take in the has_umr flag and, accordingly, > account for wrapping on either 14 or 16 bit pi/ci difference. > > Fixes: d55c9f637263 ("regex/mlx5: add data path scattered mbuf process") It is fixing a patch in this series, right? Why not squashing them?