netdev
[Top] [All Lists]

Re: Re: packet re-ordering on SMP machines.

To: "Andi Kleen" <ak@xxxxxxx>
Subject: Re: Re: packet re-ordering on SMP machines.
From: "Mohd. Mohtashim" <mcmohd@xxxxxxxxxxxxxx>
Date: 27 Aug 2002 13:57:27 -0000
Cc: "Xiaoliang\(David\)Wei" <weixl@xxxxxxxxxxx>, "Ben Greear" <greearb@xxxxxxxxxxxxxxx>, "Cheng Jin" <chengjin@xxxxxxxxxxxxxx>, "Cheng Hu" <chenghu@xxxxxxxxxxxxxx>, "Steven Low" <slow@xxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, "jamal" <hadi@xxxxxxxxxx>
Reply-to: "Mohd. Mohtashim" <mcmohd@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx


On Tue, 27 Aug 2002 Andi Kleen wrote :
>
>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?
>
>Yes.
>
>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.
>
>-Andi
>




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