[Top] [All Lists]

Re: packet re-ordering on SMP machines.

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: packet re-ordering on SMP machines.
From: Andi Kleen <ak@xxxxxxx>
Date: Tue, 27 Aug 2002 14:20:04 +0200
Cc: Andi Kleen <ak@xxxxxxx>, "Xiaoliang (David) Wei" <weixl@xxxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, Cheng Jin <chengjin@xxxxxxxxxxxxxx>, Cheng Hu <chenghu@xxxxxxxxxxxxxx>, Steven Low <slow@xxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <>
References: <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/
On Tue, Aug 27, 2002 at 08:05:04AM -0400, jamal wrote:
> On Tue, 27 Aug 2002, Andi Kleen wrote:
> >
> > That is because of the lock it takes. Locks are always slow.
> xtime_lock?


It also has some other overhead.

> >
> > Older kernels used gettimeoffset which ran without lock, but that was
> > changed because in some very obscure cases it could cause non monotonous
> > timestamps when the user turns on timestamp receiving to user space
> > (kernel protocols do not care)
> >
> > Possibilities:
> >
> > - Ignore the problem and switch back to gettimeoffset again
> Is it safe to call gettimeoffset without the lock?

Of course. The only problem is that the clock can be non mononotonous 
sometimes and not be in sync with gettimeofday, but at least the kernel 
users of packet timestamps do not care.
The only problem is the socket option, but it is obscure enough that I 
would not worry too much about it.
> > - Switch to gettimeoffset but add some correction step for the unlikely
> > case that someone wants the timestamp from user space
> > (would be my prefered solution)
> > - Implement lockless gettimeofday like x86-64 or sparc
> > (good one too, but likely slower than last)
> ia64 seems to also have the lock.

Quick fix is to just use gettimeoffset in netif_rx again. Should 
be fine for you.


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