From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 0FBAB2C60 for ; Thu, 2 Mar 2017 15:54:35 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id v186so137344249wmd.0 for ; Thu, 02 Mar 2017 06:54:35 -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=jZrZRjCfiexPoABt1tFr47mfB5pfVzxIJ5eQGALs76o=; b=CH6kjWx9xbnr9OYitxYnVXebo0mcR3ZWjx7fpubdoOjkBFIUhVTPkaigihofp2w/HO Kls3/QmgouX4HdaN4CfKWiy3NOhWkKjU1dW53/k4rNRViQtoKS5xTbO785O0lbsFxTEN g+gT+PKEpX7wIsE7C44ZkVbUKe3dF86pn0jff6meaiHB9fndwVbyMIHco1FyP3w+dBfp 1usKKU8NYIuFDt/1pZMPlmQ1SVSKU5uYuFeHIOs3iVNxEwrP7vhTuYhRNC2bvuullsIs R5NFGNct+IZps3Wcd+PYBXMn1vWLuTjvn1Dr1rQ2Pc1BVVv1HocLUUidjmvcuh862KPI WfZg== 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=jZrZRjCfiexPoABt1tFr47mfB5pfVzxIJ5eQGALs76o=; b=tv/HZjfNQBLQ91garf8QwDB/423PyLg2qBAlIT78RuQgBbLq1GwuhMlEQWVS+HrLNr VtmahQZ+Wsd1QVBkSjjwLg4DRQgO+RKugFprSaeRnxoSut6SURoD0Xezo2m61jA8TMMA 8nYBFDLE3CzFvumPBQIXJRXDnwghcHqEmle/CMIS6QjO8vfxlrzZeuAleCifxP9OgLmc +kCBf9qU1CF3qy1k0ZFZd0H9f72SmNa4JJlT9hxNCSVjCVpqEL8RuwHYenJgOPQTwJo6 7PwYvMumugONYAWsNdFr79dJ9m38WpNNM3FaVgZqkmcRbChPXUTWpqtoSZ5CXyRD0Alh By9g== X-Gm-Message-State: AMke39mCVdiAsTmZ+06I5Mc5Ezlcre/ce2XBW2NquxLExF1u1bHHst4413/9WARASEpUgxRI X-Received: by 10.28.86.214 with SMTP id k205mr7975149wmb.26.1488466474501; Thu, 02 Mar 2017 06:54:34 -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 j39sm11099687wrj.45.2017.03.02.06.54.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 Mar 2017 06:54:34 -0800 (PST) Date: Thu, 2 Mar 2017 15:54:32 +0100 From: Olivier Matz To: Andrew Rybchenko Cc: , , , , , , , , , Message-ID: <20170302155432.7e81e969@platinum> In-Reply-To: References: <1479981261-19512-1-git-send-email-olivier.matz@6wind.com> <1488388752-1819-1-git-send-email-olivier.matz@6wind.com> <1488388752-1819-2-git-send-email-olivier.matz@6wind.com> <8966736f-3bcb-5096-5c2b-643c65751d5f@solarflare.com> <20170302145752.38b2f820@platinum> 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 1/6] ethdev: add descriptor status API 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: Thu, 02 Mar 2017 14:54:35 -0000 > >>> + * Check the status of a Rx descriptor in the queue > >> I think it would be useful to highlight caller context. > >> Should it be the same CPU which receives packets from the queue? > > Yes, you are right it would be useful. I suggest the following sentences: > > > > This function should be called on a dataplane core like the > > Rx function. They should not be called concurrently on the same > > queue. > > The first sentence looks fine. "They" (functions?, dataplane cores?) is > unclear for me in the second. May be the first one is simply sufficient. Ok, I'll keep the first one at least, and see if I can reword the second one to make it clear. > >>> + * > >>> + * @param port_id > >>> + * The port identifier of the Ethernet device. > >>> + * @param queue_id > >>> + * The Rx queue identifier on this port. > >>> + * @param offset > >>> + * The offset of the descriptor starting from tail (0 is the next > >>> + * packet to be received by the driver). > >>> + * @return > >>> + * - (RTE_ETH_DESC_AVAIL): Descriptor is available for the hardware to > >>> + * receive a packet. > >>> + * - (RTE_ETH_DESC_DONE): Descriptor is done, it is filled by hw, but > >>> + * not yet processed by the driver (i.e. in the receive queue). > >>> + * - (RTE_ETH_DESC_USED): Descriptor is unavailable (hold by driver, > >>> + * not yet returned to hw). > >> It looks like it is the most suitable for descriptors which are reserved > >> and never used. > > Can you give some more details about what is a reserved but never > > used descriptor? (same question for Tx) > > Our HW has a requirement to keep few descriptors always unused (i.e. > some gap between tail and head). It is just a few descriptors, but > invalid descriptor status may misguide application. E.g. if Rx queue > size is 512 and offset 510, it will always be unused (since it is > reserved). It is not an indication that core is too slow and can't keep > the pace. Understood. I can change _USED into _UNAVAIL (add it for Tx), with the following description: - (RTE_ETH_DESC_UNAVAIL): Descriptor is unavailable: either hold by driver and not yet returned to hw, or reserved by the hardware.