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 932BBA0562; Thu, 4 Mar 2021 02:37:00 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EA8140FDF; Thu, 4 Mar 2021 02:36:59 +0100 (CET) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id 1763740147 for ; Thu, 4 Mar 2021 02:36:57 +0100 (CET) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DrYMg4JDbz16G9y; Thu, 4 Mar 2021 09:35:11 +0800 (CST) Received: from [10.78.49.194] (10.78.49.194) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Thu, 4 Mar 2021 09:36:48 +0800 To: Ferruh Yigit , , dev References: <1614130139-42926-1-git-send-email-oulijun@huawei.com> <1614693534-27620-1-git-send-email-oulijun@huawei.com> <1614693534-27620-5-git-send-email-oulijun@huawei.com> <09496901-e85a-5070-aa62-b91f0d2d4586@intel.com> <1b7a1a3d-0763-5af3-de9f-8b67919c964f@huawei.com> From: oulijun Message-ID: Date: Thu, 4 Mar 2021 09:36:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.78.49.194] X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [Linuxarm] Re: [PATCH V2 04/14] net/hns3: add Rx and Tx bytes stats 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" 在 2021/3/3 22:24, Ferruh Yigit 写道: > On 3/3/2021 2:08 PM, oulijun wrote: >> >> >> 在 2021/3/3 21:28, Ferruh Yigit 写道: >>> On 3/2/2021 1:58 PM, Lijun Ou wrote: >>>> From: "Min Hu (Connor)" >>>> >>>> In current HNS3 PMD, Rx/Tx bytes from packet stats are not >>>> implemented. >>>> >>>> This patch implemented Rx/Tx bytes using soft counters. >>>> Rx/Tx bytes stats will be enabled if the macro >>>> RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS is defined. >>>> >>>> Signed-off-by: Min Hu (Connor) >>>> Signed-off-by: Lijun Ou >>>> --- >>>> drivers/net/hns3/hns3_rxtx.c | 24 ++++++++++++++++++++++++ >>>> drivers/net/hns3/hns3_rxtx_vec_neon.h | 15 +++++++++++++++ >>>> drivers/net/hns3/hns3_rxtx_vec_sve.c | 11 +++++++++++ >>>> drivers/net/hns3/hns3_stats.c | 22 ++++++++++++++++++---- >>>> 4 files changed, 68 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/net/hns3/hns3_rxtx.c >>>> b/drivers/net/hns3/hns3_rxtx.c >>>> index 5e79177..a8bd2cc 100644 >>>> --- a/drivers/net/hns3/hns3_rxtx.c >>>> +++ b/drivers/net/hns3/hns3_rxtx.c >>>> @@ -2181,6 +2181,10 @@ hns3_recv_pkts(void *rx_queue, struct >>>> rte_mbuf **rx_pkts, uint16_t nb_pkts) >>>> cksum_err); >>>> hns3_rxd_to_vlan_tci(rxq, rxm, l234_info, &rxd); >>>> +#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS >>>> + /* Increment bytes counter */ >>>> + rxq->basic_stats.bytes += rxm->pkt_len; >>>> +#endif >>> >>> copy/paste from previous version: >>> >>> Why statistics enabled only with macro? >>> It is not common to use macro to enable the stats, what do you think >>> to remove it, to be consistent with rest of the PMDs? >> I'm sorry. I thought it was a success. >> Firstly, the macro is used to control the statistics to ensure >> performance and facilitate flexible usage. For example, the macro >> needs to be disabled when high performance is required. >> secondly the byte statistics of other vendors are implemented by >> reading and writing registers. Therefore, macros are not used.By the >> way, the MLX driver has a precedent (code snippets can be intercepted >> here). > > It is not convenient for a user re-compile the DPDK to be able to get > the ethdev byte statistics, stats are not developer/debug information, > end user may need them. And this recompilation may not be an option for > the distributed software. > > How much performance affect it has if you enable it always? > We theoretically analyzed that being on a critical path might have a performance impact. Maybe the actual mountain is negligible. > And just to double check, isn't there a way to get this information from > HW without calculating it in the driver? > OK > The compile time flags, specially after meson switch, hard to enable and > a little hidden, it is very easy to have broken code there, that is why > it better to prevent compile time flags as much as possible. > . After internal analysis, you can accept your comments and remove macros. I will fix it. >