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 4630EA00BE; Wed, 29 Apr 2020 15:38:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BFA721DA27; Wed, 29 Apr 2020 15:38:40 +0200 (CEST) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by dpdk.org (Postfix) with ESMTP id 08C871DA1C for ; Wed, 29 Apr 2020 15:38:39 +0200 (CEST) Received: by mail-wr1-f51.google.com with SMTP id k1so2587788wrx.4 for ; Wed, 29 Apr 2020 06:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=veaLTGQhYYH+n1Rxyw1kS6DG0UTerDS1AspRMOGkOig=; b=UyWHRVP5ve6C2Wsu9/zdCWpI9iy6l6R3yAozYuxM/N6LKbE+XSY4XP85f97tkh4YPz z/Sv9heiBduQ6WRXUE4PVyxayv4QE9GRjOYMN0mkcL2FChw5vwciZn38hvJtJ5A0mIv1 z/Uy+tPdbTOUQ97XW4nbZ2wt8G+znw/lGSIbfaIMw1nfb7Zz2r1x4sgOfG02ni1Q3m1O mjZcwIETiguE8UkzMI7Brn1d041H+OIqYO6BEs/GRvMDmMKJxn9SiN0lfY6lwrXxsxj6 PMxJVM9uKk1W5uqmmP47u28yRjmgJoADcm5ZzsZQwHbtuWAjMRPCEBfkXFT346QZ1kDL xZbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=veaLTGQhYYH+n1Rxyw1kS6DG0UTerDS1AspRMOGkOig=; b=UNcHyXS7KMfkydZXJalc3W3JwZvHfStJpQhCFRDUs7qVD148DfSKW19brJShHgUmly MhL5XPJP9CKpTYIjCOVYbmet/7AbwA60BtDegPm5mAgsCIQ6ql5lSc7UxGzDRpNRXKoG H6JsqfUJDEjdsS2R5jhUC5159TteXUllsiCX+c/HTkIPI/DarVTSJVd7tQdcfjBzjpbf BL5H7EZ7b0icfX6Nt7B5QSQGHugNh9rEuftMpSJltYa63it5g1UQLjboC72D4QyO7Y18 yQDLqGxjeEskjEzsUJafug9zUMrtvyBtvWJtUMSjoEBp3HLckXvh8ZE6J7to6WZqLZRL PB2g== X-Gm-Message-State: AGi0Pub9yC6DdXXGFhcD3Hj5rmz+GhtyxpciGqs1YbPk6W2GDSjyK8GI aDCTtGd2sGMvfIqNDuuQLun83w== X-Google-Smtp-Source: APiQypIG56yEqAO1mfMe1HhMdbYRJ6yxR1nLYL51s65s66rtlAQ72NXKWHebgAZlgBBVpO4HvRrocw== X-Received: by 2002:a5d:6504:: with SMTP id x4mr42015477wru.164.1588167518658; Wed, 29 Apr 2020 06:38:38 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id d7sm29581265wrn.78.2020.04.29.06.38.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 06:38:37 -0700 (PDT) Date: Wed, 29 Apr 2020 15:38:37 +0200 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, "Ananyev, Konstantin" , Honnappa Nagarahalli Message-ID: <20200429133837.GY6327@platinum> References: <98CBD80474FA8B44BF855DF32C47DC35C60F96@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F96@smartserver.smartshare.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [RFC] ring: count and empty optimizations 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" Hi Morten, On Tue, Apr 28, 2020 at 03:53:15PM +0200, Morten Brørup wrote: > Olivier (maintainer of the Ring), I'm not anymore, CC'ing Konstantin and Honnappa. > I would like to suggest a couple of minor optimizations to the ring library. > > > 1. Testing if the ring is empty is as simple as comparing the producer and consumer pointers: > > static inline int > rte_ring_empty(const struct rte_ring *r) > { > - return rte_ring_count(r) == 0; > + uint32_t prod_tail = r->prod.tail; > + uint32_t cons_tail = r->cons.tail; > + return cons_tail == prod_tail; > } > > In theory, this optimization reduces the number of potential cache misses from 3 to 2 by not having to read r->mask in rte_ring_count(). This one looks correct to me. > 2. It is not possible to enqueue more elements than the capacity of a ring, so the count function does not need to test if the capacity is exceeded: > > static inline unsigned > rte_ring_count(const struct rte_ring *r) > { > uint32_t prod_tail = r->prod.tail; > uint32_t cons_tail = r->cons.tail; > uint32_t count = (prod_tail - cons_tail) & r->mask; > - return (count > r->capacity) ? r->capacity : count; > + return count; > } > > I cannot even come up with a race condition in this function where the count would exceed the capacity. Maybe I missed something? Since there is no memory barrier, the order in which prod_tail and cons_tail are fetched is not guaranteed. Or the thread could be interrupted by the kernel in between. This function may probably return invalid results in MC/MP cases. We just ensure that the result is between 0 and r->capacity.