[Click] polling patch for e1000-7.3.20

[Massimiliano Poletto]

Yes, that reset in poll_on() is the key thing that Matt did to get the
driver working.  In addition to the occasional 254-packet hang (which
also seemed to be fixed by disabling the new 7.x copybreak code), the
reset solves the problem of crashes during click-install under load.

max

On 1/17/07, Roman Chertov <rchertov at purdue.edu> wrote:
> Also I noticed that now in the poll_on the driver essentially gets
> reset.  I tried a similar approach before but never invested the time to
> make it reset properly.  I have seen cases (just like you) where the
> driver upon a click-unload will stop at 254 packets and never TX
> anymore; however, unloading/reloading e1000 driver usually fixed the
> problem.  So I guess the new poll_on method is pretty similar to just
> restarting the whole device :)
>
> Roman
>
> Massimiliano Poletto wrote:
> > On 1/17/07, Roman Chertov <rchertov at purdue.edu> wrote:
> >> Why did you change the default ring parameters from 256 to 64?
>
>
> >
> > That was Matt's idea.  He experimented with different settings via
> > ethtool, and found that 64 gave better performance on the IBM boxes.
> > It makes no difference on the Intel boxes, which have slightly lower
> > receive and forwarding rates despite faster CPUs and generally better
> > hardware specs.  Currently we don't have an explanation for 64 vs.
> > 256, nor for why the theoretically faster hardware is slower.  It's
> > just what we observed.
> >
> > Note also that with the current driver the packet counts reported by
> > 'ifconfig ethX' do not change unless you run 'ethtool -S ethX'.  We'll
> > try to fix that.
> >
> > max
> >
>
>