Re: NetBSD 5.1 TCP performance issue (lots of ACK)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Nov 03, 2011 at 02:22:27PM -0500, David Young wrote:
> On Wed, Nov 02, 2011 at 08:04:40PM +0100, Manuel Bouyer wrote:
> > On Sat, Oct 29, 2011 at 10:14:18PM +0200, Martin Husemann wrote:
> > > On Sat, Oct 29, 2011 at 10:02:10PM +0200, Manuel Bouyer wrote:
> > > > OK, I see. But, is there a platoform where BUS_DMASYNC_PREREAD is not
> > > > a NOP ? I can't what kind of work BUS_DMASYNC_PREREAD could have to do 
> > > > ...
> > > 
> > > On platforms with memory reordering it might be a barrier (i.e. sparc64 
> > > does
> > > a membar_sync() for it).
> > 
> > So does x86. But I think it's redundant with the POSTREAD (which is also
> > a barrier) we'll do later.
> 
> It looks to me, too, like the x86 implementation will make a redundant
> x86_lfence() call.
> 
> I think it is preferable for the bus_dma implementation to try to avoid
> redundant operations than for MI drivers to try to do so.  What do you
> think?

Back to this old question I missed

It's not clear to me how the bus_dma implementation could avoid
redundant calls here. I think PREREAD and POSTREAD should both
be a barrier. I'm not sure we can avoid redundant barriers anyway,
as we can't mix, e.g. POSTREAD with PREWRITE.

Back to this specific case, the PREREAD not needed on every loop because,
when descriptors are updated, wm_add_rxbuf() will do a PREREAD|PREWRITE.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--