netdev
[Top] [All Lists]

Re: packet re-ordering on SMP machines.

To: Cheng Jin <chengjin@xxxxxxxxxxxxxx>
Subject: Re: packet re-ordering on SMP machines.
From: Andi Kleen <ak@xxxxxxx>
Date: Tue, 27 Aug 2002 19:33:03 +0200
Cc: Andi Kleen <ak@xxxxxxx>, jamal <hadi@xxxxxxxxxx>, "Xiaoliang (David) Wei" <weixl@xxxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, Cheng Hu <chenghu@xxxxxxxxxxxxxx>, Steven Low <slow@xxxxxxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.33L0.0208271011040.27776-100000@orchestra.cs.caltech.edu>
References: <20020827142004.C4358@wotan.suse.de> <Pine.LNX.4.33L0.0208271011040.27776-100000@orchestra.cs.caltech.edu>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.22.1i
On Tue, Aug 27, 2002 at 10:22:13AM -0700, Cheng Jin wrote:
> Hi, Andi,
> 
> > Quick fix is to just use gettimeoffset in netif_rx again. Should
> > be fine for you.
> 
> There doesn't appear to be a function called gettimeoffset in 2.4.18
> anymore.  The closest I found was do_fast_gettimeoffset in
> "arch/i386/kernel/time.c"  This appears to be the unlocked version that

Yes, I mean do_fast_gettimeoffset.
> you are referring to, except I can't tell why the higher 32 bits (edx) of
> the timestamp isn't used.  (maybe the asm code takes care of it, but it seems
> that the result is stored in edx so)

32bit precision are probably enough for this.

> 
> What you said about a light-weight gettime function makes sense.  For our
> purpose of timing RTTs, any gettime function with a resolution higher than
> 1 ms will probably be enough.  The time doesn't need to be in exactly in sync
> with the one obtained from the locking version of the gettime function.

TSC should be fine then.

-Andi

<Prev in Thread] Current Thread [Next in Thread>