From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 15EC3A0547; Fri, 12 Feb 2021 16:12:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D420422A2A1; Fri, 12 Feb 2021 16:12:24 +0100 (CET) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by mails.dpdk.org (Postfix) with ESMTP id 3F1EE22A29E for ; Fri, 12 Feb 2021 16:12:23 +0100 (CET) Received: by mail-oi1-f180.google.com with SMTP id h6so10298698oie.5 for ; Fri, 12 Feb 2021 07:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7r6CZ92cJyDpvFv5RABC9lE6HBAMFGduUT2yqIAPCgs=; b=SuQQ1W1dh6vYYX91cVAw/hV7qNMQJyn2iwbB8XDKmaSHTpiwfu4uMMQLMtOjgfR5FD fb3uooudXy4pHtiSWIju2d+S58Hr/TThObf+QfM8YYyFPSzM5aJBYLIMHKvFFmhszDjI K7FzdiklQyP3/7m7uapOMXdtJz6Q11CtWQc70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7r6CZ92cJyDpvFv5RABC9lE6HBAMFGduUT2yqIAPCgs=; b=fFPwNoi4r+hCNdQxuGhuUGWsTzh8yiz1yoOW45j2cP3SsdZdWxpgtmfV4u57fQ6hEd vIioJg22hIIAcxI6TWwlv4QA0xB9cp+zme73hsYZiZoABTvo4+rHwO5Pq16TFfcnzUsO ju8iIfNN2ktUahuXvzXbXWebXkk2HyzS6Gd2zP+99mkCsxXuJxpA5p2Jbp7vUcByDIfl 6LmIXEg0i7yFCStpcwZgY3o9o2AOGObJYwU4snvaMp6PpyzN9gw4J8MSJ7XGc4HTZbt8 pn3/YycVQWexppQAzqTIGPIH4j49RROKUh3LIGsGdR5hnNmMGJJ/+PFHWJ99lOdKhJKi 1O2w== X-Gm-Message-State: AOAM531rON/HmXt8L1CidkSefGlN05BtcbaG+SvtPUmssmhmSnBZFlg8 lKh4MlJMlK3mGXSkDG0pwqkevck3u4Am0bnz8nqkGQ== X-Google-Smtp-Source: ABdhPJyMwknma5spKHucZ2XnySB0tP5YrBoNvUB89vWG1OS9YFymsQOmfiX3jYKYoVPEBT7YOM6o8VZFkPq11uWPqXY= X-Received: by 2002:aca:3b06:: with SMTP id i6mr2057905oia.81.1613142742470; Fri, 12 Feb 2021 07:12:22 -0800 (PST) MIME-Version: 1.0 References: <20210211194434.172212-1-lance.richardson@broadcom.com> <8e2ba062-eba4-e7f9-cfd7-888e41a16183@intel.com> In-Reply-To: <8e2ba062-eba4-e7f9-cfd7-888e41a16183@intel.com> From: Lance Richardson Date: Fri, 12 Feb 2021 10:12:11 -0500 Message-ID: To: Ferruh Yigit Cc: Xiaoyun Li , dev@dpdk.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000027097605bb251077" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH 21.05] app/testpmd: support show Rx queue count X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" --00000000000027097605bb251077 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 12, 2021 at 6:51 AM Ferruh Yigit wrote: > > On 2/11/2021 7:44 PM, Lance Richardson wrote: > > Add support for querying receive queue count in order to allow > > the rte_eth_dev rx_queue_count() API to be exercised and tested. > > > > +1 to adding this feature, but the naming is a little misleading, "Rx queue > count", it looks like it will print the number of Rx queues, and the API has the > same problem indeed. > > Can you please clarify it that it is to get number of used descriptor in a Rx queue? > And "used descriptor" part also needs some explanation I think. > That makes sense, fixed in v2. > > There is already an existing command: > "show port rxq|txq desc status" > > What do you think adding the new one as something like: > "show port rxq desc used count" Sounds good, v2 is updated to use that form. > > +show rxq count > > +~~~~~~~~~~~~~~~~~~~~~~~~~ > > The '~' line length should be same as header length > Fixed in v2. > > + > > +Display the number of ready descriptors on a given RX queue:: > > Can you please describe more, what is "ready descriptor"? > > The 'rte_eth_rx_queue_count()' API should be returning number of descriptors > filled by HW. > I took a stab at this in v2, but maybe it could be expanded more. As I understand it, the returned descriptor count should correspond to the number of packets that could be received in the next call to the burst receive function... not necessarily the hardware-specific notion of a descriptor, which might include descriptors used for chained mbufs, LRO metadata, async status messages from firmware, etc. Thanks, Lance --00000000000027097605bb251077--