Re: [RFC] using mmiowb() in dev->poll() method

["David S. Miller" <davem@redhat.com>]

On Wed, 6 Oct 2004 11:24:19 -0700 (PDT)
<akepner@sgi.com> wrote:

> Currently, returning 0 from "dev->poll()" indicates that the 
> PIO write which enables interrupts has been flushed to the NIC 
> (or at least that's my understanding.) The change below allows 
> "dev->poll()" to return with that PIO write pending, but not 
> necessarily flushed. This allows a potentially expensive PIO 
> flush to be avoided. I've found that this can significantly 
> reduce CPU utilization and improve throughput. 

Of course, this is a known area for exploration to some of
us already.

There is a similar place for this kind of toying around in
tg3_interrupt()'s disabling of the chips IRQs.  e1000 optimizes
things in this area, last time I checked.

You have to be really careful when doing things like this.
I think your dev->poll() case would work.  In theory the
write can be posted for a long time but I doubt that matters
in practice.

I intend to play around in this area of the tg3 driver some time
soon.