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 5A277A04A3; Mon, 3 Jan 2022 15:23:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4FB340042; Mon, 3 Jan 2022 15:23:11 +0100 (CET) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by mails.dpdk.org (Postfix) with ESMTP id BDF3A4003C for ; Mon, 3 Jan 2022 15:23:10 +0100 (CET) Received: by mail-lj1-f178.google.com with SMTP id p7so55265492ljj.1 for ; Mon, 03 Jan 2022 06:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gdoBEl6zqgwxd+FqkUT+Ug9xzujwhEQvS1hAGN7Gvms=; b=Uw0qxJZDiM4TCLy8dHnI2ea8WZXMopPmq3rHFvFLazYEbMrZFh9gwJWo/QlZJA5cy4 /28iQgsUO/wPQKIeedubikHxFtYXLUvtKDzDg8ncnR8iunH60BqRubN+0NaU+Fy2yIm+ YjdFhf37awexyM4gznmGMLb0Hi3CzbGoXjAJstuFr9dtIDdpVCw/tzXZBf7lGC6lp/Ln BiB/j6SasDUZ6ZJeIeol5v+gcwgZgRJhG6TmReqF5OddNReSS0CS7lo3i361D2/AnOcf FB0dXWDGp3wmokkBp6oN2/CLLp5Wya4mXIkjEEoW9rglpPkn5M8AbLryqj4Hu9dayE8P egng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gdoBEl6zqgwxd+FqkUT+Ug9xzujwhEQvS1hAGN7Gvms=; b=Fn6bF2J9Tuo684sA2zQRVOtwLzd9mEEOcz4mLM3Jfz8ZtmQKtJdg99EqmH/RCjNFRI ThGj+F2JLAdv0gJEjBcDlxlc7LFdrS19nFy6jdlW/YGQiRJPPfopKMVi8gzWDzEHNiPY E4LxDDBF11gm1hEkAI37ByL7dnedsoJ1NQCyX1oOtUARHMXZELOjZHnAcf9SFmo4ipbr 910xd5oHajgRZmLPBWwpLafEwdEF8if88l04bPgsXoPJipIrDzKETACMYjx9TOFewhKs +SM1lp+h84H9fR7x0Yu9X5a0JX5sv0ZrWxX9o7bYbMAljIh83NohufMrfEwt0Jn0X2/X 4ofg== X-Gm-Message-State: AOAM533ABbUPSOpBfeKQajMDIsqTpHZFqcJ1UB6jBkw8y6u8iKOS/z2t lgQZDek1KCnrF2GRl23tIa8fgdGD63DxEg== X-Google-Smtp-Source: ABdhPJyUZ1L/cnNwYvDX7pGpAORqUPP806LfX3OOh8cb8ZWaLJMvR/+FhgXE9ak/zuweZMReucmUEQ== X-Received: by 2002:a2e:83cd:: with SMTP id s13mr38767613ljh.373.1641219790254; Mon, 03 Jan 2022 06:23:10 -0800 (PST) Received: from andrzejo-l.semihalf.net ([83.142.187.84]) by smtp.googlemail.com with ESMTPSA id p19sm3420800ljj.17.2022.01.03.06.23.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jan 2022 06:23:09 -0800 (PST) From: Andrzej Ostruszka To: dev@dpdk.org Cc: upstream@semihalf.com, Andrzej Ostruszka Subject: [PATCH 0/1] Minor mistake in ring (en|de)queueing Date: Mon, 3 Jan 2022 15:22:00 +0100 Message-Id: <20220103142201.475552-1-amo@semihalf.com> X-Mailer: git-send-email 2.34.1.448.ga2b2bfdf31-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Hi all, Recently I was going through the ring implementation and I believe I've found a small mistake. Not a functional error, just a slightly suboptimal behaviour for the specific case when we want to enqueue exactly the number of elements that we can before wrapping to the ring beginning (the same goes for dequeueing). Imagine we have a ring of size 16 depicted below with indexes underneath and consumer/producer pointing as shown. | ****** | 0123456789ABCDEF ^ ^ c p Now if we try to enqueue 8 elements we will end up at the check: if (likely(idx + n < size)) { where idx (=8) is a producer head and n=8. We will fail this check even though we have the case of 8 elements available without wrapping to the beginning of the ring. I hope I'm not completely off the base here :), if I'm not then the subsequent patch attempts to fix this. Wit regards Andrzej Ostruszka Andrzej Ostruszka (1): ring: fix off by 1 mistake lib/ring/rte_ring_elem_pvt.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.34.1.448.ga2b2bfdf31-goog