From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f68.google.com (mail-pl0-f68.google.com [209.85.160.68]) by dpdk.org (Postfix) with ESMTP id 009C756A1 for ; Fri, 9 Mar 2018 02:48:30 +0100 (CET) Received: by mail-pl0-f68.google.com with SMTP id m22-v6so4408358pls.5 for ; Thu, 08 Mar 2018 17:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vUp4ipYzeF5Dv4MeBlKZnbOPm0ExHDKB+JJr7trVwF8=; b=zyB8KHNmVZNSXgBMOxuRcFjYPWnpj7Icg3/5K/PwJO1IJ/wH/+woyZjIIFkOo0Lhte LZes1pJ2x5sD3lR2r25JrD9gX0JbfQsP9Mx07RsczHmyjJ6f1aG1dAvAPiQrmWxGni7T Ndp5ifsR4CdS7kXIOt2wh85C14hixmSsDVsa7VW0L/m94r5riMsRaV0Y/1dxIUv43/lc zCQs3yGc3BT2VMeR4xC6e/r9tDnoVf9i9qu937D+iTxJjIgRxz0V9P/UnITAGtbgnf0q 55gBOOPTI93dymW1Q+CKQdVQfKtsbNzv+dSZ35ExP2bExvIffWLpEs/yNYqD5oSlzGax 9Q9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vUp4ipYzeF5Dv4MeBlKZnbOPm0ExHDKB+JJr7trVwF8=; b=PUOP/aY1ddjO4ezUgaCRs+/wxLTedT/QP4QukEvxqyEYQ7o5Q1K7FopnMmYdvmWNLn UJJ9YI2gbQ6bexW4iBATht1zLt5hJxv1DHSqziOwBcUGfL2Eui4ewg2A5eKxakixxOnG fQsQTiW80BBRK/3UlCgkat95Hf/y52vSn5MVWgnO8o89cUJOAM00J/p/mlfUJCsuhsj0 QxBMAJXdWR8IhLpevB7f9J53xKQURl1lqCfgLJmKAcRA+aw4XeWgPklqXTc7asri7b2U 65gkJhT2+sq7ypEzQOKgErbcFqcNkoQ0aeGyMOdvnOOeUuLP/TF6uj+4iDszC1j6eAe7 oGMA== X-Gm-Message-State: APf1xPBub0ZpYy60oH16dtUgiHHKFqPjPcRTz5EwBpgM6MyY2+vrKbXi nR7X3SdPPSpHXqQwZIQFX8XABg== X-Google-Smtp-Source: AG47ELsOG8+XPSIT7Qt467AIaFqOXCsuy+UEkaLA6iS+fWiDekXa/mO2ACwv8lzbcAHRc0ppEA8TgQ== X-Received: by 2002:a17:902:2823:: with SMTP id e32-v6mr25939583plb.44.1520560110119; Thu, 08 Mar 2018 17:48:30 -0800 (PST) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id q87sm43880586pfa.29.2018.03.08.17.48.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Mar 2018 17:48:30 -0800 (PST) Date: Thu, 8 Mar 2018 17:48:27 -0800 From: Stephen Hemminger To: Hyong Youb Kim Cc: John Daley , ferruh.yigit@intel.com, dev@dpdk.org Message-ID: <20180308174827.68ee4683@xeon-e3> In-Reply-To: <20180309005253.GA19460@HYONKIM-FTCPE.cisco.com> References: <20180306014634.28398-2-johndale@cisco.com> <20180308024702.25974-1-johndale@cisco.com> <20180308024702.25974-9-johndale@cisco.com> <20180308141427.08475f17@xeon-e3> <20180309005253.GA19460@HYONKIM-FTCPE.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 08/10] doc: describe Rx bytes counter behavior for enic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 01:48:31 -0000 On Fri, 9 Mar 2018 09:52:54 +0900 Hyong Youb Kim wrote: > On Thu, Mar 08, 2018 at 02:14:27PM -0800, Stephen Hemminger wrote: > > On Wed, 7 Mar 2018 18:47:00 -0800 > > John Daley wrote: > > > > > 'catch-all' filters should be added last. > > > > > > +- **Statistics** > > > + > > > + - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B). > > > + - When the NIC drops a packet because the Rx queue has no free buffers, > > > + ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or > > > + VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping > > > + is enabled. > > > > All drivers must provide consistent statistics! > > That means do NOT include CRC in the rx byte counts. > > Yes, several drivers in DPDK are already broken for this. > > > > Otherwise there are cases like packets being forwarded from HW NIC to virtio and the counts > > differ and customers think data is lots. > > Thanks for sharing this specific use case issue. > > We are aware that our current counters are non-standard. Newer 100G > hardware models have fixed the problem (i.e. no CRC bytes, no > incrementing of bytes when no buffers). We plan to update the doc > again when we add these newer models to the supported hardware list. > > As for older models, we will see if we can fix up stats in software.. > > -Hyong Don't worry some of the Intel drivers are buggy last I checked. Also make sure that when forwarding that bytes transmitted == bytes received. There were some drivers adding CRC on the receive but no on transmit. It maybe true that you want to count CRC if the CRC stripping flag is not set.