netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Chan" <mchan@broadcom.com>
To: "David Miller" <davem@davemloft.net>
Cc: mcarlson@broadcom.com, "netdev" <netdev@vger.kernel.org>,
	andy@greyhouse.net
Subject: Re: [PATCH 10/13] tg3: Increase the PCI MRRS
Date: Thu, 15 Nov 2007 15:51:31 -0800	[thread overview]
Message-ID: <1195170691.5745.10.camel@dell> (raw)
In-Reply-To: <20071115.144103.24280158.davem@davemloft.net>

On Thu, 2007-11-15 at 14:41 -0800, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Thu, 15 Nov 2007 14:20:10 -0800
> >
> > Keeping the MRRS at 512 introduces DMA latencies that effectively
> > prevent us from achieving linerate.  With a packet size of ~1.5K and the
> > MRRS at 512 bytes, the DMA will be broken into at least 3 DMA reads.
> > Each DMA read takes ~1usec to initiate.  It is this overhead that starts
> > to cut into total throughput.
> 
> Ok, but wouldn't every networking device on PCI need to do this then?

No, it depends on the design.  For example, a bigger maximum payload
size will alleviate the problem (tg3 hardware is using 128).  Multiple
DMA read channels to pipeline the multiple read requests will also help.

We don't need to increase the MRRS on bnx2 hardware to get line-rate,
for example.

> 
> I want to hear what you think about this wrt. what I mentioned about
> fairness above.  What's the point of PCI specifying a limit to comply
> with if nobody complies with the limit for localized performance
> reasons?

Fairness is harder to know because it depends on chipset behavior.  PCIE
is not shared so there's no fairness issue at the local PCIE.  Any
fairness issue will be at the bridge.

I don't know what's the exact rationale for defaulting to 512, but I
will try to find out.

> 
> I think this is an important issue.  Someone down the road is going to
> see bad disk throughput when doing lots of network transfers and
> wonder why that is.  It will be hard to debug, but it won't be
> difficult for us to do something proactive about this right now to
> prevent that problem from happening in the first place.
> 
> Thanks.
> 


  reply	other threads:[~2007-11-15 23:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10  0:39 [PATCH 10/13] tg3: Increase the PCI MRRS Matt Carlson
2007-11-13  5:21 ` David Miller
2007-11-15 22:20   ` Matt Carlson
2007-11-15 22:41     ` David Miller
2007-11-15 23:51       ` Michael Chan [this message]
2007-11-15 23:08         ` David Miller
2007-11-16  0:32       ` Rick Jones
2007-11-16  2:17         ` Michael Chan

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=1195170691.5745.10.camel@dell \
    --to=mchan@broadcom.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=mcarlson@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /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).