Re: re(4) driver dropping packets when reading NFS files

> 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 also possible it wrapped
> multiple times. Could you verify that?
> 
Ill look, but since the test was run just after booting the machine,
if it wrapped it would mean that it dropped even more packets, I
think?

> > >
> > > >From my limited testing, it seems it works as expected. Would you
> > > give it try and let me know how well it behaves with NFS?
> > >
> > Without DEVICE_POLLING it behaves just like the unpatched one.
> >
> 
> Hmm, that's strange. Are you sure you rebuilt kernel without polling
> option? Just disabling polling with ifconfig(8) has no effect to
> make patch work.
> 
Yep. I have two kernel configs and I rebuilt/installed using the one
that doesn't have DEVICE_POLLING. (Also, I would have seen about 9Mbytes/sec
read rate if I was using the one that has DEVICE_POLLING.)

> 
> 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.
> 
Agreed. There is definitely an issue for at least this variant of the chip.

Is it fair to assume that, since the chip reports the missed packets, that it
thinks that it doesn't have a usable receive buffer at the time the packet is
received? (I'm thinking that it couldn't have used up 256 receive buffers when
the first drop happens, since I see it early in the tcpdump I took before, so
maybe something related to handling of the receive ring? As I said, I'll play
with it later to-day and let you know if I learn something more.)

rick