In message <199806130859.BAA27553@cue.bc.ca>  John Nemeth wrote:
> On Jun 10, 12:41am, Stefan Grefen wrote:
> } In message <199806092202.PAA10864@lestat.nas.nasa.gov>  Jason Thorpe wrote:
> } > On Tue, 09 Jun 1998 23:25:15 +0200 
> } >  Stefan Grefen <grefen@hprc.tandem.com> wrote:
> } > 
> } >  > I aggree, but please with a additional switch. This is helpful for
> } >  > driver development but not for daily use.
> } > 
> } > The DEBUG option isn't really "for daily use", either...  I guess you
> } > and I disagree on the semantics of the DEBUG option.
> } 
> } The problem is the message goes away without DEBUG, but a 'fixed'
> } driver stays. I can add a ifdef DEBUG in the driver around the 
> 
>      The message goes away when the driver is fixed too.

It is no fixed. This a copyout to the card. I've read it any way the
way it is. All I con do is go to a slower copyout. It is the final use
of the buffer so aligning doesn't buy a thing.
I would agree for a copyin from the card ...

> } > 
> } > That's only because your m_pullup() does a copy; there are other ways of
> } > dealing with the problem.  See the CS8900 that _IS_ in the SUP tree at
> } 
> } I'm using ports, so it has to be 2 byte access and I think insw beats 
> } any other solution. Doing a dance through a tmp variable may be faster than 
> 
>      Sure, just make sure the buffer you put the data in is properly
> aligned.

Good idea, this is the lowest level of a network driver so we try to backtrace
it up to the socket-layer and hope for the best ??

I think you missed the point were it happens.

> 
> } You stop doing that if you play with bigger machines in your day-time job.
> 
>      This is very unfortunate.  I think about performance issues all
> the time.  Just because you have a big machine doesn't mean you can
> get sloppy.  Bigger machine generally have bigger problems to solve,
> and being sloppy means you need a much bigger machine.

Depending on what you do, concentrating on elimiating latency is more
important, you can always buy a faster machine if your short on CPU-cycles.
(That doesn't i don't care about them, just that the importance of latency
issues is much higher).
Or as a well known performace guru said:
You can buy bandwidth, but latency is here to stay ....

Stefan

> 
> }-- End of excerpt from Stefan Grefen

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---