From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 2FDBB2B98 for ; Tue, 31 Jan 2017 11:53:53 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id v77so87619664wmv.0 for ; Tue, 31 Jan 2017 02:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bWL2s6UzIh98fUXbxkzy0+w134wFZCnZtXqFYfcgF3k=; b=LqO22VEPYLtaEjs63R9eaMU1zv4X8S61H4h068IggpV6BHr3o7B5g/WVtiF2j4+uRK kkji4i366o1petd+mQCm2G61JDfte2lQOcGjyj08mjtrcGTUJXqiL7NvLK1E6ImiSTst RxRzQRSwRNzT5d72hmchjvbMNGTQY1AyNkA/CX4H1VoOlgXZDFi6oinT1bjmbt/ZG04q LToGusID1cQ/Mw+ItAk3nsv+UZKGZgWbl7NdMeo+37CcUUdFWu5NipihHfJNw4j3LBWo sDJN5urAdeFU92qX4MyDz7GzeEw8DADrb+lSdcWxlhXk27cU5jBYB5Biep6XstN2UsKZ o9lw== 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=bWL2s6UzIh98fUXbxkzy0+w134wFZCnZtXqFYfcgF3k=; b=a5Q2kZmYGRzwTaGYuGvBj+yKPTQUePmonn5S1Mcbpkm2cOuow+5xsYuftRa2HQC4lS TgT0NKUxIcSfPtigDBdz+3yCxY9e5lOD4OYibOUWD8EKSBrJXpaXh6FO0F62DYQ8SkGU JpPb4fhYRNS94ql0FnrxgW2HJTUulZeniHQis/6dYpnE3Gi2ATWpj+MeCoTeTfyamIez 1+E70gaXLMy0c1LnJ8/cUDeJuv1JYM915FTy3RO93bHQbWlBUQHYjLy+u71ITollwk0Y eehlgkZOARcgYjAKOOQnMsKnpTAU67miDmT0o/phe1oZocGr7j3a8iOF0FpeCw09QG1H kjyA== X-Gm-Message-State: AIkVDXK+zQh/Gv1YkD8ubfOTLzg67fALlsGiY4kM8qZQjMAvfJlYGWbGFSHL0yP4duJwekEC X-Received: by 10.28.191.208 with SMTP id o77mr17147429wmi.117.1485860032820; Tue, 31 Jan 2017 02:53:52 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id n10sm27706281wrb.9.2017.01.31.02.53.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Jan 2017 02:53:52 -0800 (PST) Date: Tue, 31 Jan 2017 11:53:49 +0100 From: Olivier Matz To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , "Wiles, Keith" , "dev@dpdk.org" Message-ID: <20170131115349.7efadb09@platinum> In-Reply-To: <2601191342CEEE43887BDE71AB9772583F10CD7E@irsmsx105.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> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 10:53:53 -0000 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 Olivier