On Mon, Dec 26, 2011 at 10:55:50PM -0500, Rick Macklem wrote:
Way back in Nov 2010, this thread was related to a problem I
had, where an re(4) { 810xE PCIe 10/100baseTX, according to the
driver } interface dropped received packets, resulting in a
significant impact of NFS performance.
Well,
Way back in Nov 2010, this thread was related to a problem I
had, where an re(4) { 810xE PCIe 10/100baseTX, according to the
driver } interface dropped received packets, resulting in a
significant impact of NFS performance.
Well, it turns out that a recent (post r224506) commit seems to
have
By chance, how about disabling RX early interrupt?
You can add the following 3 lines of code into re_init_locked().
2710 /*
2711 * Set the initial RX configuration.
2712 */
2713 re_set_rxmode(sc);
2714
2715 /* Disable RX early interrupt. */
2716 cfg = CSR_READ_2(sc, RL_MULTIINTR);
I've added a counter of how many times re_rxeof() gets called, but
then
returns without handling any received packets (I think because
RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv.
ring.)
This count comes out as almost the same as the # of missed frames
(see
I highly doubt it could be hardware issue.
Looks like the hardware guys may be off the hook. See below.
It's job of bus_dma(9) and I don't think barrier instructions would
be helpful here as I don't see out-of-order execution in RX
handler.
My current hunch is that something that
On Sun, Nov 07, 2010 at 07:06:44PM -0500, Rick Macklem wrote:
I highly doubt it could be hardware issue.
Looks like the hardware guys may be off the hook. See below.
It's job of bus_dma(9) and I don't think barrier instructions would
be helpful here as I don't see out-of-order
If that made difference, all other ethernet controllers would have
suffered from the similar issues.
Well, some commit done between June 7 and June 15 made a difference,
but I have no idea what or why.
Also, I had a report of very poor read rate from someone using a bge(4)
interface, but I
On Sun, Nov 07, 2010 at 08:14:31PM -0500, Rick Macklem wrote:
If that made difference, all other ethernet controllers would have
suffered from the similar issues.
Well, some commit done between June 7 and June 15 made a difference,
but I have no idea what or why.
Also, I had a
On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote:
If the counter was not wrapped, it seem you lost more than 10% out
of
total RX frames. This is a lot loss and there should be a way to
mitigate it.
I've attached a patch (to the if_re.c in head, not your patched
On Fri, Nov 05, 2010 at 07:44:56PM -0400, Rick Macklem wrote:
On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote:
If the counter was not wrapped, it seem you lost more than 10% out
of
total RX frames. This is a lot loss and there should be a way to
mitigate it.
On Fri, Nov 05, 2010 at 07:33:45PM -0700, Pyun YongHyeon wrote:
[...]
If this theory is correct, the attached patch may mitigate the
issue.
Oops, I incorrectly used old code.
Please use this one.
Index: sys/pci/if_rlreg.h
===
On Wed, Nov 03, 2010 at 07:27:20PM -0400, Rick Macklem wrote:
I'm more interested in number of dropped frames. See below how to
extract that information.
I've attached the stats. I'm guessing that the
Rx missed frames : 14792
is the culprit.
Because that counter is 16bit
If the counter was not wrapped, it seem you lost more than 10% out of
total RX frames. This is a lot loss and there should be a way to
mitigate it.
I've attached a patch (to the if_re.c in head, not your patched variant)
that works a lot better (about 5Mbytes/sec read rate). To get that, I
On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote:
If the counter was not wrapped, it seem you lost more than 10% out of
total RX frames. This is a lot loss and there should be a way to
mitigate it.
I've attached a patch (to the if_re.c in head, not your patched variant)
I'm more interested in number of dropped frames. See below how to
extract that information.
I've attached the stats. I'm guessing that the
Rx missed frames : 14792
is the culprit.
This was for a read of a fairly large file via NFS over TCP,
getting a read rate of about 450Kbytes/sec. (No
On Wed, Nov 03, 2010 at 07:27:20PM -0400, Rick Macklem wrote:
I'm more interested in number of dropped frames. See below how to
extract that information.
I've attached the stats. I'm guessing that the
Rx missed frames : 14792
is the culprit.
Because that counter is 16bit it's
On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote:
I recently purchased a laptop that has a re(4) Realtek 8101E/8102E/8103E net
chip in it and I find that it is dropping packets like crazy when reading
files over an NFS mount. (It seems that bursts of receive traffic cause it,
since
On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote:
I recently purchased a laptop that has a re(4) Realtek
8101E/8102E/8103E net
chip in it and I find that it is dropping packets like crazy when
reading
files over an NFS mount. (It seems that bursts of receive traffic
cause
On Mon, Nov 01, 2010 at 06:18:13PM -0400, Rick Macklem wrote:
On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote:
I recently purchased a laptop that has a re(4) Realtek
8101E/8102E/8103E net
chip in it and I find that it is dropping packets like crazy when
reading
files
19 matches
Mail list logo
