netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: David Miller <davem@davemloft.net>
Cc: mcarlson@broadcom.com, netdev@vger.kernel.org,
	andy@greyhouse.net, mchan@broadcom.com
Subject: Re: [PATCH 10/13] tg3: Increase the PCI MRRS
Date: Thu, 15 Nov 2007 16:32:38 -0800	[thread overview]
Message-ID: <473CE526.4080209@hp.com> (raw)
In-Reply-To: <20071115.144103.24280158.davem@davemloft.net>

>>>I sense that the PCI spec wants devices to use an MRRS value of 512 in
>>>order to get better fairness on a PCI-E segment amongst multiple
>>>devices.

Unless there are PCIe switches, there is only ever one device on the 
PCIe segment yes?  Even on the biggest PCI-X or PCIe systems with which 
I am familiar, each PCIe slot is a separate PCIe bus, and I think that 
holds for the most recent PCI-X one as well.

Now, "core" I/O may be another matter - for example, on the rx3600 and 
rx6600 there are some shared PCI-X bus slots (two per) and on the 
"combo" versions in addition to the two independent PCIe x8's there is 
one pair of PCIe's on a switched bus.

However, none of the shared bus slots are recommended for "high 
performance cards" (that wonderfully moving target of a devinition :).


>>>From that perspective, jacking up the MRRS to 4096 unilaterally seems
>>>like a very bad idea.  If this was necessary for good performance, I'm
>>>sure the PCI spec folks would have choosen a higher value.
>>>
>>>Or is this some tg3 specific performance issue?
>>
>>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.

Reminds me of Tigon2 on original PCI.

> Ok, but wouldn't every networking device on PCI need to do this then?

I'm going to get very rapidly out of my PCI depth, but on one or the 
other (e vs X) isn't is possible from the standpoint of PCI for a device 
to have multiple transactions outstanding at a time?

If a given device can only have one outstanding at a time and happens to 
take a while to setup the DMA (perhaps there is firmware down there or 
something) I could see where it would want to make the transactions as 
large as it could, but another device, either able to have multiple in 
flight, or perhaps quicker on the DMA setup draw might not need it so large.

And even if the device itself is reasonably quick on the DMA setup draw, 
there may be systems, particularly large ones, where the rest of the 
setup of the DMA isn't instantaneous.

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

I'm _guessing_ that much of those limits were set with shared busses in 
mind.  The "trend" seems to be towards single-slot busses.

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

Does the current value of the MRRS get displayed in lspci output?  It 
wouldn't be a slam dunk, but if someone were looking at that and saw the 
value large they might make an educated guess.

rick jones

  parent reply	other threads:[~2007-11-16  0:43 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
2007-11-15 23:08         ` David Miller
2007-11-16  0:32       ` Rick Jones [this message]
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=473CE526.4080209@hp.com \
    --to=rick.jones2@hp.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=mcarlson@broadcom.com \
    --cc=mchan@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).