From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id B873E12A8 for ; Tue, 31 Jan 2017 13:10:54 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 31 Jan 2017 04:10:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,314,1477983600"; d="scan'208";a="928523294" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga003.jf.intel.com with SMTP; 31 Jan 2017 04:10:51 -0800 Received: by (sSMTP sendmail emulation); Tue, 31 Jan 2017 12:10:50 +0000 Date: Tue, 31 Jan 2017 12:10:50 +0000 From: Bruce Richardson To: Olivier Matz Cc: "Ananyev, Konstantin" , "Wiles, Keith" , "dev@dpdk.org" Message-ID: <20170131121050.GA130444@bricha3-MOBL3.ger.corp.intel.com> References: <20170125121456.GA24344@bricha3-MOBL3.ger.corp.intel.com> <20170125142052.7989e0ec@glumotte.dev.6wind.com> <20170125135404.GA24352@bricha3-MOBL3.ger.corp.intel.com> <20170125144809.GA26936@bricha3-MOBL3.ger.corp.intel.com> <647B0F09-667B-41D2-A8E1-964F71D4C365@intel.com> <20170125165740.GA33248@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F10CD7E@irsmsx105.ger.corp.intel.com> <20170131115349.7efadb09@platinum> <20170131114142.GA130764@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170131114142.GA130764@bricha3-MOBL3.ger.corp.intel.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] rte_ring features in use (or not) 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: Tue, 31 Jan 2017 12:10:55 -0000 On Tue, Jan 31, 2017 at 11:41:42AM +0000, Bruce Richardson wrote: > On Tue, Jan 31, 2017 at 11:53:49AM +0100, Olivier Matz wrote: > > On Wed, 25 Jan 2017 17:29:18 +0000, "Ananyev, Konstantin" > > wrote: > > > > > > Bonus question: > > > > > > * Do we know how widely used the enq_bulk/deq_bulk functions > > > > > > are? They are useful for unit tests, so they do have uses, but > > > > > > I think it would be good if we harmonized the return values > > > > > > between bulk and burst functions. Right now: > > > > > > enq_bulk - only enqueues all elements or none. Returns 0 > > > > > > for all, or negative error for none. > > > > > > enq_burst - enqueues as many elements as possible. Returns > > > > > > the number enqueued. > > > > > > > > > > I do use the apis in pktgen and the difference in return values > > > > > has got me once. Making them common would be great, but the > > > > > problem is > > > > backward compat to old versions I would need to have an ifdef in > > > > pktgen now. So it seems like we moved the problem to the > > > > application. > > > > > > > > > > > > > Yes, an ifdef would be needed, but how many versions of DPDK back > > > > do you support? Could the ifdef be removed again after say, 6 > > > > months? > > > > > I would like to see the old API kept and a new API with the new > > > > > behavior. I know it adds another API but one of the API would be > > > > > nothing > > > > more than wrapper function if not a macro. > > > > > > > > > > Would that be more reasonable then changing the ABI? > > > > > > > > Technically, this would be an API rather than ABI change, since the > > > > functions are inlined in the code. However, it's not the only API > > > > change I'm looking to make here - I'd like to have all the > > > > functions start returning details of the state of the ring, rather > > > > than have the watermarks facility. If we add all new functions for > > > > this and keep the old ones around, we are just increasing our > > > > maintenance burden. > > > > > > > > I'd like other opinions here. Do we see increasing the API surface > > > > as the best solution, or are we ok to change the APIs of a key > > > > library like the rings one? > > > > > > I am ok with changing API to make both _bulk and _burst return the > > > same thing. Konstantin > > > > I agree that the _bulk() functions returning 0 or -err can be confusing. > > But it has at least one advantage: it explicitly shows that if user ask > > for N enqueues/dequeues, it will either get N or 0, not something > > between. > > > > Changing the API of the existing _bulk() functions looks a bit > > dangerous to me. There's probably a lot of code relying on the ring > > API, and changing its behavior may break it. > > > > I'd prefer to deprecate the old _bulk and _burst functions, and > > introduce a new api, maybe something like: > > > > rte_ring_generic_dequeue(ring, objs, n, behavior, flags) > > -> return nb_objs or -err > > > Don't like the -err, since it's not a valid value that can be used e.g. > in simple loops in the case that the user doesn't care about the exact > reason for error. I prefer having zero returned on error, with rte_errno > set appropriately, since then it is trivial for apps to ignore error > values they don't care about. > It also makes the APIs in a ring library consistent in that all will set > rte_errno on error, rather than returning the error code. It's not right > for rte_ring_create and rte_ring_lookup to return an error code since > they return pointers, not integer values. > > As for deprecating the functions - I'm not sure about that. I think the > names of the existing functions are ok, and should be kept. I've a new > patchset of cleanups for rte_rings in the works. Let me try and finish > that and send it out as an RFC and we'll see what you think then. > Sorry, I realised on re-reading this reply seemed overly negative, sorry. I can actually see the case for deprecating both sets of functions to allow us to "start afresh". If we do so, are we as well to just replace the whole library with a new one, e.g. rte_fifo, which would allow us the freedom to keep e.g. functions with "burst" in the name if we so wish? If might also allow an easier transition. Regards, /Bruce