All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Kyle Larose <eomereadig@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: How can I calculate/estimate pps(packet per seocond) and bps(bit per second) in DPDK pktg
Date: Tue, 3 Nov 2015 15:28:50 -0800	[thread overview]
Message-ID: <20151103152850.3e23f639@xeon-e3> (raw)
In-Reply-To: <CAMFWN9=3m0u9TC5TP3v1yCn-7kNLqWwf8-eCCtONL5vygSwZxA@mail.gmail.com>

On Tue, 3 Nov 2015 17:18:31 -0500
Kyle Larose <eomereadig@gmail.com> wrote:

> On Tue, Nov 3, 2015 at 5:05 PM, Stephen Hemminger
> <stephen@networkplumber.org> 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.

No. configuration is the enemy of usability.
Why does DPDK have to behave differently than BSD and Linux, what possible
value could this be to the end user?

> 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.

  reply	other threads:[~2015-11-03 23:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03  6:25 How can I calculate/estimate pps(packet per seocond) and bps(bit per second) in DPDK pktg 최익성
2015-11-03 14:11 ` Wiles, Keith
2015-11-03 14:30   ` Van Haaren, Harry
2015-11-03 14:33     ` Wiles, Keith
2015-11-03 15:59       ` Polehn, Mike A
2015-11-03 19:00         ` Wiles, Keith
2015-11-03 21:55           ` Polehn, Mike A
2015-11-04  1:45         ` 최익성
2015-11-04 14:21           ` Polehn, Mike A
2015-11-04 23:58             ` 최익성
2015-11-03 22:05     ` Stephen Hemminger
2015-11-03 22:18       ` Kyle Larose
2015-11-03 23:28         ` Stephen Hemminger [this message]
2015-11-04 13:13           ` Kyle Larose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151103152850.3e23f639@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=eomereadig@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.