From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id BDC8F2BF1 for ; Tue, 23 Aug 2016 11:45:56 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2DCB681245; Tue, 23 Aug 2016 09:45:56 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-4-170.ams2.redhat.com [10.36.4.170]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7N9jsMn001472; Tue, 23 Aug 2016 05:45:55 -0400 To: "Yang, Zhiyong" , "dev@dpdk.org" References: <1471608966-39077-1-git-send-email-zhiyong.yang@intel.com> <08c5733b-6758-2d98-df4a-a2261ecf43e4@redhat.com> From: Panu Matilainen Message-ID: <45bf611c-fbd5-d485-566a-5752cd58ed7c@redhat.com> Date: Tue, 23 Aug 2016 12:45:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 23 Aug 2016 09:45:56 +0000 (UTC) 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: Tue, 23 Aug 2016 09:45:57 -0000 On 08/23/2016 11:04 AM, Yang, Zhiyong wrote: > Hi, Panu: > >> -----Original Message----- >> From: Panu Matilainen [mailto:pmatilai@redhat.com] >> Sent: Monday, August 22, 2016 3:53 PM >> To: Yang, Zhiyong ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] vhost: add pmd xstats >> >> On 08/19/2016 03:16 PM, Zhiyong Yang wrote: >>> This feature adds vhost pmd extended statistics from per queue >>> perspective for the application such as OVS etc. >>> >>> The statistics counters are based on RFC 2819 and 2863 as follows: >>> >>> rx/tx_good_packets >>> rx/tx_total_bytes >>> rx/tx_dropped_pkts >>> rx/tx_broadcast_packets >>> rx/tx_multicast_packets >>> rx/tx_ucast_packets >>> rx/tx_undersize_errors >>> rx/tx_size_64_packets >>> rx/tx_size_65_to_127_packets; >>> rx/tx_size_128_to_255_packets; >>> rx/tx_size_256_to_511_packets; >>> rx/tx_size_512_to_1023_packets; >>> rx/tx_size_1024_to_1522_packets; >>> rx/tx_1523_to_max_packets; >>> rx/tx_errors >>> rx_fragmented_errors >>> rx_jabber_errors >>> rx_unknown_protos_packets; >>> >>> No API is changed or added. >>> rte_eth_xstats_get_names() to retrieve what kinds of vhost xstats are >>> supported, >>> rte_eth_xstats_get() to retrieve vhost extended statistics, >>> rte_eth_xstats_reset() to reset vhost extended statistics. >>> >>> 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. - Panu - > > -zhiyong- >