From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by dpdk.org (Postfix) with ESMTP id 64DD48E86 for ; Tue, 3 Nov 2015 23:18:32 +0100 (CET) Received: by oifu63 with SMTP id u63so17895450oif.2 for ; Tue, 03 Nov 2015 14:18:31 -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-type; bh=9Hry+cxxT2SXpswjfwpt6EBQb1ozoK1chL6r2uhlg+g=; b=ihISRRExqPFkYPnIYgCq6ZqsQhS5AJMnA5m4TB6PaBCF3YHYnJ9aYAC26beVl0rXmX U4GoL/ljxkS4eLag21ehKP/qNfQJbbt6rz0K7IokqL/Z2mAWMvXgwXvhq5Rhs0LmkZz8 xvmhlDqHWnXan3Ogv2prQ+rViE6G1KvVqH7RMSEn4dd/hIuBLSLi4gY2oqGrnQJ6a/GF iz0E74ylqbAqaJDO3k9ebjxtQTOsqY61Ptr4cGjHH3TDEWypdQ6ZwI1UhnqQPs+ZpeOc +P1yIqK/M8yCw/B1kj1VqsLlcGoaEQpHnrzXNpwZ9YKL1TrADHTiwdrJSKC5LcItlRsF 2A1w== MIME-Version: 1.0 X-Received: by 10.202.79.130 with SMTP id d124mr15133574oib.13.1446589111889; Tue, 03 Nov 2015 14:18:31 -0800 (PST) Received: by 10.76.68.202 with HTTP; Tue, 3 Nov 2015 14:18:31 -0800 (PST) In-Reply-To: <20151103140531.677eee6d@xeon-e3> References: <514E811C-1D85-4BB7-AA9C-C5D2B2ED6043@intel.com> <20151103140531.677eee6d@xeon-e3> Date: Tue, 3 Nov 2015 17:18:31 -0500 Message-ID: From: Kyle Larose To: Stephen Hemminger Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] How can I calculate/estimate pps(packet per seocond) and bps(bit per second) in DPDK pktg 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, 03 Nov 2015 22:18:32 -0000 On Tue, Nov 3, 2015 at 5:05 PM, Stephen Hemminger wrote: > > IMHO this is a bug. Other drivers don't include the CRC, and the Intel driver > only includes CRC in count for one direction, and depends on value of stripping flag. > > I sent a patch to fix this because our customers didn't like it when Rx != Tx bytes > but there was somebody who liked including CRC. > > It really is a Cisco versus the world thing. Juniper/Linux/BSD all do NOT include > CRC in counters and therefore that is what should be done. > Another option is to make whether or not the NIC counts the CRC in its byte counters configurable, when supported, and also retrievable. I'm concerned about the case where a NIC doesn't even have an option to control whether or not it counts the CRC, and it *does* count it. In that case, any software running on that NIC will behave inconsistently. If it knew that it counted the CRC, it could adjust for it. If we put the option in now, then software written now could deal with it gracefully. Combined with the ability to configure it, this may satisfy use cases where knowing the full frame size is useful (for example when looking at bit rates with small packets. 4 bytes is a big difference for a 64-byte frame). Of course, this may not be a problem worth solving. But, I figure it's worth considering.