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 59541532C for ; Wed, 24 Aug 2016 10:44:35 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id o80so16081301wme.1 for ; Wed, 24 Aug 2016 01:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=waY13joOQ7MrArMdQ8PHQaPnr/zrRqori9To7lTu8Uk=; b=117l5dUUKV4jxpBb34s1y3Hbb3/GXloys6kDin3+/rPGUcYymg3nx09/w87nSHK25U hx6xdv0chJEAHmyvC631PNemv3vm2u65XDulTXHDGmWRHad/h3bDq0evFs4oK1iCsKWs CGV4BOF7/IFqxYCU56CxY7Cmvb9+fGrSFN4VIytz1Gg8v5q5zfJT/IDCBEIhAeXNocar saShqVmH7poxdyxdLOecTbP+lTl8QeVrWSJKjaR5xZA2p1aNOfdeO3q11iFVI9Txiqo5 QN39g3deYuHqlY9lP2IWjxanxuyJ8K2hLpi5Z747RLcxqWkv4toRfWjgaFykkBdZIEiH 34Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=waY13joOQ7MrArMdQ8PHQaPnr/zrRqori9To7lTu8Uk=; b=dgruKFYb9q8f4g0tUY1zC8JvkIRgxqRVXKMVffH3OBqLA6xpYA5CSCKHiDXWK5tG8J AanFjOrr/Prijcy7mOzn5/8cj4wDyuVbGsbTz85B1bugLT91+YKfCEE0oViyclILSu+Y 9v8o3Y/sYzGlxQLPtkd2moCa779hXundX97OFvWYcQOHtVkryDqRAYYKoi/NuefEEL59 XFXQOk4w7Hm9xgf3+KEBs0uCE5zksHXf0IUAgOJykoHr6RNM0EHmz909imUecD/z4b59 7xM0nZ4S8WR63k5GWQQHZNf92PIkWEvsooXft7xRLTPxDNlOrPmn1vol55YO/3okgirJ 5ZXg== X-Gm-Message-State: AEkoouuccn6c2ZJXrpkgpVUpKhoGgesLzjPNIfxdNSw7jBv1CUc+RUdpmJ20UKb45pqwSmPH X-Received: by 10.194.221.232 with SMTP id qh8mr1688418wjc.117.1472028275065; Wed, 24 Aug 2016 01:44:35 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id n2sm8769020wjd.1.2016.08.24.01.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Aug 2016 01:44:33 -0700 (PDT) From: Thomas Monjalon To: Yuanhan Liu Cc: dev@dpdk.org, Panu Matilainen , "Yang, Zhiyong" Date: Wed, 24 Aug 2016 10:44:33 +0200 Message-ID: <3180838.i4arGqJgvX@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160824054602.GS30752@yliu-dev.sh.intel.com> References: <1471608966-39077-1-git-send-email-zhiyong.yang@intel.com> <45bf611c-fbd5-d485-566a-5752cd58ed7c@redhat.com> <20160824054602.GS30752@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] vhost: add pmd xstats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 08:44:35 -0000 2016-08-24 13:46, Yuanhan Liu: > On Tue, Aug 23, 2016 at 12:45:54PM +0300, Panu Matilainen wrote: > > >>>Since collecting data of vhost_update_packet_xstats will have some > > >>>effect on RX/TX performance, so, Setting compiling switch > > >>>CONFIG_RTE_LIBRTE_PMD_VHOST_UPDATE_XSTATS=n by default in the > > >>file > > >>>config/common_base, if needing xstats data, you can enable it(y). > > >> > > >>NAK, such things need to be switchable at run-time. > > >> > > >> - Panu - > > > > > >Considering the following reasons using the compiler switch, not > > >command-line at run-time. > > > > > >1.Similar xstats update functions are always collecting stats data in the > > >background when rx/tx are running, such as the physical NIC or virtio, > > >which have no switch. Compiler switch for vhost pmd xstats is added > > >as a option when performance is viewed as critical factor. > > > > > >2. No data structure and API in any layer support the xstats update switch > > >at run-time. Common data structure (struct rte_eth_dev_data) has no > > >device-specific data member, if implementing enable/disable of vhost_update > > >_packet_xstats at run-time, must define a flag(device-specific) in it, > > >because the definition of struct vhost_queue in the driver code > > >(eth_vhost_rx/eth_vhost_tx processing)is not visible from device perspective. > > > > > >3. I tested RX/TX with v1 patch (y) as reference based on Intel(R) > > >Xeon(R) CPU E5-2699 v3 @ 2.30GHz, for 64byts packets in burst mode, 32 packets > > >in one RX/TX processing. Overhead of vhost_update_packet_xstats is less than > > >3% for the rx/tx processing. It looks that vhost_update_packet_xstats has a > > >limited effect on performance drop. > > > > Well, either the performance overhead is acceptable and it should always be > > on (like with physical NICs I think). Or it is not. In which case it needs > > to be turnable on and off, at run-time. Rebuilding is not an option in the > > world of distros. > > I think the less than 3% overhead is acceptable here, that I agree with > Panu we should always keep it on. If someone compains it later that even > 3% is too big for them, let's consider to make it be switchable at > run-time. Either we could introduce a generic eth API for that, Or > just introduce a vhost one if that doesn't make too much sense to other > eth drivers. +1 It may have sense to introduce a generic run-time option for stats.