From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org, Stephen Hemminger <shemming@brocade.com>
Subject: Re: [dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count
Date: Thu, 9 Jul 2015 16:03:37 -0700 [thread overview]
Message-ID: <20150709160337.3ba72cae@urahara> (raw)
In-Reply-To: <1556408.e2XOMCRvgs@xps13>
On Wed, 01 Apr 2015 09:45:02 +0200
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 2015-03-24 23:54, Ananyev, Konstantin:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > On Mon, 23 Mar 2015 16:45:44 +0000
> > > "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of stephen@networkplumber.org
> > > > > From: Stephen Hemminger <shemming@brocade.com>
> > > > >
> > > > > The ixgbe driver was including CRC in the transmit packet byte
> > > > > count, but not for packets received.
> > > > > This was notice when forwarding and
> > > > > the number of bytes received was greater than the number of bytes transmitted
> > > > > for the same number of packets. Make the driver behave like other
> > > > > virtual devices and not include CRC in byte count. Use the same queue
> > > > > counters already computed and used for Rx.
> > > >
> > > > About RX side stats - as I remember it depends to what value hw_stip_crc is set at configure().
> > > > If hw_stip_crc==1, then, yes CRC bytes are not included into QBRC value.
> > > > I If hw_stip_crc==0, then CRC bytes are included into QBRC.
> > >
> > > That is an additional bug!
> > > * CRC should never be included in the byte count.
> > > This is not how Linux or other drivers report byte count.
> >
> > I don't have any strong opinion here...
> > For me any method (with or without CRC) of counting bytes are ok, as long as this method is identical across all PMDs we support.
> > Which makes we wonder, what approach other PMDs use?
> >
> > >
> > > * the byte count must be symmetrical Rx == Tx
> > >
> > > The Brocade router always set strip_crc to 1. So did not see the additional bug
> > > of CRC being included in byte count.
> >
> > Are you going to submit v2, to make Rx==Tx for both cases?
>
> Any conclusion?
> Without update, this patch is going to be dropped.
My conclusion was that CRC should never be in byte count regardless of
configuration because that is what everyone (except CISCO) expects.
My patch did that.
next prev parent reply other threads:[~2015-07-09 23:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 23:54 Ananyev, Konstantin
2015-04-01 7:45 ` Thomas Monjalon
2015-07-09 23:03 ` Stephen Hemminger [this message]
[not found] ` <c8d4fd5c400c4beaa4577b8b1069fe04@BRMWP-EXMB12.corp.brocade.com>
2015-04-01 18:36 ` Stephen Hemminger
2015-07-09 22:59 ` Thomas Monjalon
-- strict thread matches above, loose matches on Subject: below --
2015-01-23 6:23 stephen
2015-01-27 10:11 ` Thomas Monjalon
2015-01-27 11:38 ` Stephen Hemminger
2015-03-04 20:55 ` Thomas Monjalon
[not found] ` <9265c0d3b03e4f33b7823139be7b3b91@BRMWP-EXMB11.corp.brocade.com>
2015-03-04 23:06 ` Stephen Hemminger
2015-03-23 14:08 ` Thomas Monjalon
2015-03-23 16:45 ` Ananyev, Konstantin
2015-03-24 15:55 ` Stephen Hemminger
2015-04-02 20:20 ` Butler, Siobhan A
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=20150709160337.3ba72cae@urahara \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=shemming@brocade.com \
--cc=thomas.monjalon@6wind.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).