From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id B23A6D142 for ; Tue, 14 Mar 2017 09:56:38 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id 196so12240168wmm.1 for ; Tue, 14 Mar 2017 01:56:38 -0700 (PDT) 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=Q+H3AfhbM1IOcpevlqDytQD/GgfbfdvADGpiJiVHhBM=; b=G10ziuhUgasQzTucOH3e83BOy3lTvaWP85eSqESgUEmNHVzDbv6y3oCVfaKTHyVWiK mIgHpczgyNOS5dwMGp3psurvFHVQw5dQKSYeRL5VzJHnc4yWW5HNCf1LvNRk8l9PiFqY L9MqdhNkXU5+MkiwHb2B648xxM7WktIi+pLyzE/f5JSnMY/dhxuQos61AG6WEV3hvm62 1w/4so8oJav3awLGdkui9SNJ4El86goILsmpd+c4npeuAj1XFLJdOKBGDoQozDwCYt+k /vYRzlURhPQHk5E1eGK7MAh2FBH1vWyf7iIynqWLPfa5l6BS7esjhhjl1zqRUpsIs7+Q 3HYQ== 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=Q+H3AfhbM1IOcpevlqDytQD/GgfbfdvADGpiJiVHhBM=; b=DBhECpPZrUo6mQz4zGymnhDcuoOyWuV37C7Pp1sEW7Ozb9NVZ1YU6bKnM0I7YHA+fE tHMQMkjevzgScxEjSg/e8uAhv69xd85fsurQdGu/lp+dE/ZDwHoFmBy2Myj3vQ/GHXlr zsqu2nwFnq027RkGTFMfbMz7ALsh9VYgjPmu/1+S766wLK9cn0JHpQQIVa+aebn3X5cP LCZu26lsUDnW0Pw5uQ8rvzQrfXSPfcy5QqShph5H71S+JDbu7yrR8JcsiwzIjKTFKpxG W+HJtnhWplLi/Ufu9x4Uo+6de+/zDDxkewMexLFrbBXUSl4kg3UNP3O2aFS2xUxmtLOX Plcw== X-Gm-Message-State: AFeK/H3PUyQbjqZyWYPD1gRy0xQYqyqtpjikVMrPXQIA3L1hqef7UbNFbhfbxUoVrUhpknW8 X-Received: by 10.28.12.147 with SMTP id 141mr14680324wmm.8.1489481798102; Tue, 14 Mar 2017 01:56:38 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id b199sm14560625wmb.13.2017.03.14.01.56.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Mar 2017 01:56:38 -0700 (PDT) Date: Tue, 14 Mar 2017 09:56:35 +0100 From: Olivier Matz To: Bruce Richardson Cc: jerin.jacob@caviumnetworks.com, dev@dpdk.org Message-ID: <20170314095635.2a5e6c8b@platinum> In-Reply-To: <20170308120842.GB286404@bricha3-MOBL3.ger.corp.intel.com> References: <20170223172407.27664-1-bruce.richardson@intel.com> <20170307113217.11077-1-bruce.richardson@intel.com> <20170307113217.11077-8-bruce.richardson@intel.com> <20170308112240.31bcb9e5@glumotte.dev.6wind.com> <20170308120842.GB286404@bricha3-MOBL3.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] [PATCH v2 07/14] ring: make bulk and burst fn return vals consistent 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, 14 Mar 2017 08:56:38 -0000 On Wed, 8 Mar 2017 12:08:42 +0000, Bruce Richardson wrote: > On Wed, Mar 08, 2017 at 11:22:40AM +0100, Olivier MATZ wrote: > > On Tue, 7 Mar 2017 11:32:10 +0000, Bruce Richardson wrote: > > > The bulk fns for rings returns 0 for all elements enqueued and negative > > > for no space. Change that to make them consistent with the burst functions > > > in returning the number of elements enqueued/dequeued, i.e. 0 or N. > > > This change also allows the return value from enq/deq to be used directly > > > without a branch for error checking. > > > > > > Signed-off-by: Bruce Richardson > > > > [...] > > > > > @@ -716,7 +695,7 @@ rte_ring_enqueue_bulk(struct rte_ring *r, void * const *obj_table, > > > static inline int __attribute__((always_inline)) > > > rte_ring_mp_enqueue(struct rte_ring *r, void *obj) > > > { > > > - return rte_ring_mp_enqueue_bulk(r, &obj, 1); > > > + return rte_ring_mp_enqueue_bulk(r, &obj, 1) ? 0 : -ENOBUFS; > > > } > > > > > > /** > > > > I'm wondering if these functions (enqueue/dequeue of one element) should > > be modified to return 0 (fail) or 1 (success) too, for consistency with > > the bulk functions. > > > > Any opinion? > > > I thought about that, but I would view it as risky, unless we want to go > changing the parameters to the function also, as the compiler won't flag > a change in return value like that. > Ok, I have no better solution anyway. Olivier