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.
>
>
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 fixed
>
> 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_MULTI
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
>
> 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
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-o
>
> 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 tha
> > 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 fr
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 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
> >
> 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,
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 v
>
> 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
> 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.
> >
>
> Becaus
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 16
>
> 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. (N
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
> > > read
> 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 traffi
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,
> si
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 when I look over wireshark, typically the 2nd packet in a read rep
20 matches
Mail list logo
