From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FA23A00E6 for ; Thu, 8 Aug 2019 12:37:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2B2AA1BDEC; Thu, 8 Aug 2019 12:37:56 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id B83B81B9FA; Thu, 8 Aug 2019 12:37:52 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us5.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id C5934A4005C; Thu, 8 Aug 2019 10:37:50 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 8 Aug 2019 11:37:41 +0100 To: Thierry Herbelot , CC: Olivier Matz , , Thomas Monjalon References: From: Andrew Rybchenko Message-ID: <383dda49-4474-1b78-bc70-8cfef305233f@solarflare.com> Date: Thu, 8 Aug 2019 13:37:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [85.187.13.152] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24832.000 X-TM-AS-Result: No-10.973400-8.000000-10 X-TMASE-MatchedRID: 6lay9u8oTUPsYbGmK/WYxvZvT2zYoYOwC/ExpXrHizzzlv7FEwWOy8qm rem+KXPd+GOpgqc8lxcfWekSZjAGEYpCwExx8AipPwKTD1v8YV5UENBIMyKD0dEsTITobgNENDU gttty4FVZVPxvRQjmVAJfVW3wuXXE7ns6Ai0dhJniHyvyXeXh5tLSQvQHx+rQVz8J52OVy+SNhV Uy0CfBHVQrQWfNw93S30vSa4XfhzneG4FwcWqAS8Oh48ZKiK0PF9s8UTYYetUELMPQNzyJS6yAQ bvPfXXm4tGaU7p1kmObOgSAVyxuqpmRr1k6e+lgn6EaUt26riWfM+smQZqWkITa63gQe8yZ7Bif Hc/dwcYISC67Y7Dw4v0GGkeErTDa6mAjMMIfjznnvg/SfqXd/czzMs2dyeyV4Vo4xoaXBy9bdMV tkzOVLOfOVcxjDhcwAYt5KiTiutmJhnKtQtAvVsRB0bsfrpPIfiAqrjYtFiSwO4B/sbdzFLQNWu 4UG39eerePSZpC+XbxWa2RICV8y37cGd19dSFd X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--10.973400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24832.000 X-MDID: 1565260672-Ru7JTl99Oewb Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 19.11 V3 02/12] ethdev: fix description of tx descriptor status X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 8/8/19 11:22 AM, Thierry Herbelot wrote: > From: Olivier Matz > > The API comment of rte_eth_tx_descriptor_status() was incorrect. The > reference descriptor (when offset = 0) is not where the next packet > will be sent, but where the latest packet has been enqueued. > > Fixes: 52f5cdd2e897 ("ethdev: add descriptor status API") > Cc: stable@dpdk.org > > Signed-off-by: Olivier Matz > --- > lib/librte_ethdev/rte_ethdev.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index dc6596bc93b4..b423e71050e9 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -4245,8 +4245,8 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id, > * @param queue_id > * A valid Tx queue identifier on this port. > * @param offset > - * The offset of the descriptor starting from tail (0 is the place where > - * the next packet will be send). > + * The offset of the descriptor starting from tail (0 is the last written > + * descriptor). > * > * @return > * - (RTE_ETH_TX_DESC_FULL) Descriptor is being processed by the hw, i.e. The patch lacks explanation why it was wrong before and why it is correct after the patch. I think there is a space here for description improvements since it is still confusing. I'd suggest to remove 'tail' term from the description or write down full description to explain what/where is head and tail. Rx case:          V-->offset =========***********----------------00000000000==  UNAVAIL     DONE        AVAIL        UNUSED i.e. V points to the next packet to be received by the driver, i.e. the first * (the descriptor is done by HW and packet is ready to be processed). DONE(*) are descriptors filled in by HW, but not processed by the driver yet. AVAIL(-) are available for HW to fill in with received packets. UNUSED(0) (right now it is UNAVAIL as well) are descriptors which can be done AVAIL on Rx queue refill UNAVAIL(=) are reserved Rx ring space which cannot be used The key question for Rx is the length of DONE. Is CPU fast enough to handle incoming traffic? Tx case (where is tail V and why): =========************--------------00000000000==  UNAVAIL     DONE          FULL       UNUSED DONE(*) are descriptors processed by HW and should be processed by the driver to free associated mbuf (rte_eth_tx_done_cleanup()) FULL(-) are available for HW to send these packets out, but not processed yet. UNUSED(0) is available space in Tx ring to make it FULL UNAVAIL(=) is reserved Tx ring space which cannot be used I'd say that it should be similar to Rx here, but it looks different in accordance with current description. Above patch fixes it from the first '-' (or the first '0'?) to be the last '-'. What is the main question for Tx status descriptor user?