From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by dpdk.org (Postfix) with ESMTP id 18E7D58D6 for ; Fri, 26 Feb 2016 16:18:21 +0100 (CET) Received: by mail-oi0-f44.google.com with SMTP id m82so63665803oif.1 for ; Fri, 26 Feb 2016 07:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=/Eq7V0cvs4JYVglYLgcsq0JUdGEhN0otQU4uqsbszjY=; b=nOUQbIDlPApeehxdNDtPLi+3VjJrq+UHr1hKj5at6S4eb7Ww60vjt9x4/5UwMlsXxi rqfN30mbj2eWrKKsPLmGo5A3ec0dact/EiyipbqDBFJI5xlIJsercLggfMGyd8/jueI0 N4Sm8+SGxJrrTpzO6J73trEAJwoVbeAz2j745kjJI4Uyq4AKXshH7Ddjc+6g1Pdr36Id 0PSMCGdXshTweJBBo9kUl4X265bJzJXFhAAPbsfRGlgb4edzADMHyFQoYB6ngC3W9VJ+ E6FCsVVGuTSEoV6o/rXJDnvM8xGjEW16yV/6D4Xzna7jqmbfO4aJ2HBRqnld8OinBxLa YDOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=/Eq7V0cvs4JYVglYLgcsq0JUdGEhN0otQU4uqsbszjY=; b=BjkrRTYH1qGxlrAG0kfoG2denA5Kpjk5U3e3P3jqZiWXRl3OR0REtkZpRvD2dQVLPQ BT97UZhF90p3o4vAPpR7fQDfYUthTGswilTJ973Ms5kvfJhiSF4rml18BpQyipDdQLua 1SOto10M4IczUoWkbznJiXGY3raqreuS0yjBiWsjKZWNqBXaebjSX54r7NHHLNFepvkN ylOVmg3LosrvIYpApEbMNEyQrmub/a1+5kQ9zlpZPA6y3D6auS9VT4bNB/rmeN+sPjVu sbYC0EdqjbMicnuDxs+ZD7PF3XXk4Z/VPoXsDeKeonjfnmxcK0ynQP6UXCDVAw6HNsmu 2Bcg== X-Gm-Message-State: AD7BkJLUBuuEZ9l9f8ynWcBIJ0kliiMBs3ixJczq4sv7B1WDuqzOsh/GgHaxpEOfcN4OE38whPEoPjjyH1Ei9w== MIME-Version: 1.0 X-Received: by 10.202.63.6 with SMTP id m6mr1486127oia.91.1456499900559; Fri, 26 Feb 2016 07:18:20 -0800 (PST) Received: by 10.76.68.7 with HTTP; Fri, 26 Feb 2016 07:18:20 -0800 (PST) In-Reply-To: References: <26CA3897-E24A-4B7B-918F-45679AA896E0@nfware.com> Date: Fri, 26 Feb 2016 10:18:20 -0500 Message-ID: From: Kyle Larose To: Igor Ryzhov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Virtio xstats problem 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: Fri, 26 Feb 2016 15:18:21 -0000 On Fri, Feb 26, 2016 at 9:35 AM, Igor Ryzhov wrote: > Hello, Harry. > > Understood about size of packets. It's a bit confusing, because in all ot= her drivers undersized packet is an error. Maybe we should add another one = size bin for virtio - 60 to 63 bytes? > I'm not sure we need to add a new bucket. According to the rmon MIB (which defines histogram counters) the undersize bucket doesn't necessarily mean that there was an error. It just means that the packet was less than 64 bytes: "The total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS octets) and were otherwise well formed." This is from https://tools.ietf.org/html/rfc2819 Now, whether we want to align with the standard is up for debate, but I think we should try to as much as possible. I guess we could add the 60-63 bucket, and then count those packets in undersized as well. There's a similar problem when mapping large packets to the rmon mib. It has an "oversized" bucket, which is everything above 1518. A packet incrementing that bucket isn't an error; it's just the "everything else" bucket in the histogram. We could also talk about the bit about it "including FCS octets", but things get a little tricky there. Do we want to assume that all packets received on a virtio interface had a 4-byte FCS at some point, and add 4 bytes to each packet? That will be true for anything coming from the wire, but for inter-VM communication over a vswitch, it may not be. > I already checked about multicast/broadcast counters - broadcast packets = are counted twice: > > vq->multicast +=3D is_multicast_ether_addr(ea); > vq->broadcast +=3D is_broadcast_ether_addr(ea); > > I think it should be something like: > > if (is_multicast_ether_addr(ea)) { > if (is_broadcast_ether_addr(ea)) { > vq->broadcast++; > } else { > vq->multicast++; > } > } > > Best regards, > Igor > >> 26 =D1=84=D0=B5=D0=B2=D1=80. 2016 =D0=B3., =D0=B2 17:29, Van Haaren, Har= ry =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >> >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Igor Ryzhov >>> I found some problem with virtio xstats counters. >>> >>> Example: >>> >>> rx_good_packets: 3 >>> rx_good_bytes: 180 >>> rx_errors: 0 >>> >>> rx_q0_good_packets: 3 >>> rx_q0_good_bytes: 180 >>> rx_q0_errors: 0 >>> >>> rx_q0_multicast_packets: 3 >>> rx_q0_broadcast_packets: 1 >>> rx_q0_undersize_packets: 3 >> >>> It means that undersize packets are counted as good packets instead of = errors. >> >> Are you sending 64 byte packets? There are no 4 bytes of CRC on virtual >> interfaces, so 60 bytes per packet is OK. >> >>> Or maybe >>> size of packet is calculated wrong. >>> I don't have time now to check it more deeply - I can do it sometime la= ter, but maybe >>> someone want to help. >> >> Are the packets multicast or broadcast? >> It looks like one of the counters there is wrong. >> >>> PS. Is it a common practice to count broadcast packets twice - in broad= cast and multicast >>> counters? >> >> No packet should be counted twice - it must be put into one bucket of mu= tli, broad or unicast. >> >> -Harry Kyle