From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id BDC852B98 for ; Tue, 31 Jan 2017 12:41:53 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 31 Jan 2017 03:41:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,314,1477983600"; d="scan'208";a="1120128557" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga002.fm.intel.com with SMTP; 31 Jan 2017 03:41:43 -0800 Received: by (sSMTP sendmail emulation); Tue, 31 Jan 2017 11:41:42 +0000 Date: Tue, 31 Jan 2017 11:41:42 +0000 From: Bruce Richardson To: Olivier Matz Cc: "Ananyev, Konstantin" , "Wiles, Keith" , "dev@dpdk.org" Message-ID: <20170131114142.GA130764@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170131115349.7efadb09@platinum> 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 11:41:54 -0000 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. Regards, /Bruce