From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id ECE58DE5 for ; Wed, 25 Jan 2017 14:20:59 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id c85so26032172wmi.1 for ; Wed, 25 Jan 2017 05:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=QhGYmsyd9dYyUSY1IcygM4DmGvMCfYnOBIRdIAVf+SU=; b=w1ruOkFdO1WRfCxBPM92d16LtC4mMYQczoXIIwy/uMqjPh3TakkgIbnlk1hrDQz7fY pVTPTOaFCNYpV74hvWiVN2mFetLVhNyFru/EwIixiS12zHMy72x502N6RlHOMlnDRHWh 9CnSgfF0LlHkb8feksxw3ocs9Izp37floJUsrVkZI1FChkri2hQ+x4NvkCUhrahIOWiO O4jrfMzX2sbStpFXCmmKdgPiZylRD52Mo/X/GDvhsfWtGoR1mfGOSr5a9pIJHHXjHihY wLZBNx3FIWCFG1ATFbXta+3mfnOTmVnyljYyIGZf4+t9YHH5ioeFxoSga+V/oQeSuDyo QIzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=QhGYmsyd9dYyUSY1IcygM4DmGvMCfYnOBIRdIAVf+SU=; b=pZPgnG2gwsgB+RAL2bexOk+ymddMnQ4sN6ewy8n2Oi47cCZmur6flrQ0/1bxq9sxfs W8Wr4Mtsmnv3Lv5ReAoE+FhNqv4LcZyqmvCnVY2W7D5fcqBQfclxzo6k0oN3TBKzFUeq y56zNitMceWU7UU7ogaLHQB9Z3DyzSQo68MvCVo8cOqS0abF5rhM37GBFkQlXAAg2JtR 2/mQ3efI+pS68Mijh8HLHVFz/MIt07U5xExVt1h5Fdcls0SF+JsZ6nDzPo4SxzalFlm0 vhiu2xD7RBEZAkuOhB6CXJwWznz90c0xl41wnmzUkzNN/5kyFj7uz0VfNkS8oxdFviRY 0CxQ== X-Gm-Message-State: AIkVDXIHYPN/Bde9iWXaIKkh6IbyRYZ7wD7ViEGoeMNbs8GFNwaJ3FME0tuWESSVwn8l3pZv X-Received: by 10.28.35.65 with SMTP id j62mr21286796wmj.31.1485350459506; Wed, 25 Jan 2017 05:20:59 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id e6sm24937156wrc.30.2017.01.25.05.20.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Jan 2017 05:20:59 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Wed, 25 Jan 2017 14:20:52 +0100 To: Bruce Richardson Cc: dev@dpdk.org Message-ID: <20170125142052.7989e0ec@glumotte.dev.6wind.com> In-Reply-To: <20170125121456.GA24344@bricha3-MOBL3.ger.corp.intel.com> References: <20170125121456.GA24344@bricha3-MOBL3.ger.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; 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: Wed, 25 Jan 2017 13:21:00 -0000 On Wed, 25 Jan 2017 12:14:56 +0000, Bruce Richardson wrote: > Hi all, > > while looking at the rte_ring code, I'm wondering if we can simplify > that a bit by removing some of the code it in that may not be used. > Specifically: > > * Does anyone use the NIC stats functionality for debugging? I've > certainly never seen it used, and it's presence makes the rest less > readable. Can it be dropped? What do you call NIC stats? The stats that are enabled with RTE_LIBRTE_RING_DEBUG? If yes, I was recently thinking almost the same about mempool stats. The need to enable stats at compilation makes them less usable. On the other hand, I feel the mempool/ring stats may be useful, for instance to check if mbufs are used from mempool cache, and not from common pool. For mempool, my conclusion was: - Enabling stats (debug) changes the ABI, because it adds a field in the structure, this is bad - enabling stats is not the same than enabling debug, we should have 2 different ifdefs - if statistics don't cost a lot, they should be enabled by default, because it's a good debug tool (ex: have a stats for each access to common pool) For the ring, in my opinion, the stats could be fully removed. > * RTE_RING_PAUSE_REP_COUNT is set to be disabled at build time, and > so does anyone actually use this? Can it be dropped? This option looks like a hack to use the ring in conditions where it should no be used (preemptable threads). And having a compile-time option for this kind of stuff is not in vogue ;) > * Who uses the watermarks feature as is? I know we have a sample app > that uses it, but there are better ways I think to achieve the same > goal while simplifying the ring implementation. Rather than have a > set watermark on enqueue, have both enqueue and dequeue functions > return the number of free or used slots available in the ring (in > case of enqueue, how many free there are, in case of dequeue, how > many items are available). Easier to implement and far more useful to > the app. +1