From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 1DB34F72 for ; Wed, 16 Jan 2019 01:34:25 +0100 (CET) Received: by mail-pl1-f194.google.com with SMTP id g9so2104095plo.3 for ; Tue, 15 Jan 2019 16:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=U2TjW5hgG+KRm4uSTG0p86BCYLZbMAffEdpk3RXMSB0=; b=u9a+RLl5+fNa/tjlnJAuboIoalSCYsTF+SUSmvmkOc2eZpdI8H5km9QybMgN/cHwgx 9bJYWtg5N2WTlosw134lG1Xp5OkCD5JZU6/b7LU+777WeFZPpac9eftBV3w2SEIcT0MZ JwdfB7bklGbXC9ByZUOM+i+MTqKibCAGUPsNe7TbcqCNkcvlyVDZEy9rz3zpD4s2z41r vm/mAhIs4HLodvy5owjGCIdRB1IohJauF4pyBWWSqp8W41vK+Qnbx+x+cIRJdOifQ+gu fBT+h3R8Z9W6HpdTfVuwp8Rf6v6CH8w2V0v/uaaJZ3AcgXKQBMzaUUqoeuH91KO1uLvv BMuQ== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=U2TjW5hgG+KRm4uSTG0p86BCYLZbMAffEdpk3RXMSB0=; b=l0+Mc+HMUo/t4KZQH6JY+iheYMg/eh+dqdrss+VGT7urf8vHsahB5xFWbawd2jhPWi pvvd7kgnFEB4IL6c3Tv+Puom+dYIVnr1GELfRJjA1AuH6R66Oq1isvVweWw5rMmMS9EF 3obA1/PViSEct8QNCozOb+NIPX9bHyTJdYho5l7nNsFGpWQuBzsUvPgpxG0lUfb6kQnS 0DjzPsdR+S1riLO1hKc8rvcyObn2BrKPyb9HR684+MgpOx6ViOvLhaVXLI+DNDrDvB2y VUrXF6O8aucKjEuXp7JINkzzn71YgOaZU4fLUR7pMoEmnomUSwsZNkNNzVbZ7yrhCn27 wpTg== X-Gm-Message-State: AJcUukdQV0V0gxBzqOex1JDzA/ZvXJHRXKmgsz1dd/h2SmV7+2Fb0D+a GQCZr4XEP26bJJFWv+j1qrw44g== X-Google-Smtp-Source: ALg8bN5xBVnfsfScHZ/EI+jW/URxuLv1DL9akiuyqpc6R6bJUpP6+Nmcq2v5HDMquEgvxJ5a/DQQrQ== X-Received: by 2002:a17:902:8484:: with SMTP id c4mr6740321plo.59.1547598864100; Tue, 15 Jan 2019 16:34:24 -0800 (PST) Received: from shemminger-XPS-13-9360 ([167.220.61.105]) by smtp.gmail.com with ESMTPSA id r8sm4928242pgr.48.2019.01.15.16.34.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Jan 2019 16:34:24 -0800 (PST) Date: Tue, 15 Jan 2019 16:34:22 -0800 From: Stephen Hemminger To: Gage Eads Cc: dev@dpdk.org, olivier.matz@6wind.com, arybchenko@solarflare.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com Message-ID: <20190115163422.01c0becb@shemminger-XPS-13-9360> In-Reply-To: <20190115235934.16065-1-gage.eads@intel.com> References: <20190115235934.16065-1-gage.eads@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: announce ring ABI and API changes 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: , X-List-Received-Date: Wed, 16 Jan 2019 00:34:25 -0000 On Tue, 15 Jan 2019 17:59:34 -0600 Gage Eads wrote: > In order to support the non-blocking ring[1], one ABI change and one API > change are required in librte_ring. This commit updates the deprecation > notice to pave the way for their inclusion in 19.05. > > [1] http://mails.dpdk.org/archives/dev/2019-January/123475.html > > Signed-off-by: Gage Eads > --- > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index d4aea4b46..d74cff467 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -83,3 +83,14 @@ Deprecation Notices > - The size and layout of ``rte_cryptodev_qp_conf`` and syntax of > ``rte_cryptodev_queue_pair_setup`` will change to to allow to use > two different mempools for crypto and device private sessions. > + > +* ring: two changes are planned for rte_ring in v19.05: > + > + - The ring head and tail values are planned to be changed from ``uint32_t`` > + to ``size_t``. This reduces the likelihood of wrap-around to effectively > + zero for 64-bit builds, which is important in avoiding the ABA problem in > + the upcoming non-blocking ring implementation. (32-bit builds are > + unaffected by this change.) > + - rte_ring_get_memsize() will get a new ``flags`` parameter, so it can > + calculate the memory required for rings that require more than 8B per entry > + (such as the upcoming non-blocking ring). Would it be possible to support new and old ring types, either through naming tricks and/or new ring flag? Changing things like ring buffer and mbuf are basically a flag day for all users. I admit to having a personal interest in this since the API/ABI churn is this project causes vendors to stay on older code. And older code does not correctly support newer networks.