From: Andi Kleen <ak@suse.de>
To: jamal <hadi@cyberus.ca>
Cc: Andi Kleen <ak@suse.de>,
"Xiaoliang (David) Wei" <weixl@caltech.edu>,
Ben Greear <greearb@candelatech.com>,
Cheng Jin <chengjin@cs.caltech.edu>,
Cheng Hu <chenghu@cs.caltech.edu>,
Steven Low <slow@cs.caltech.edu>,
netdev@oss.sgi.com
Subject: Re: packet re-ordering on SMP machines.
Date: Tue, 27 Aug 2002 14:20:04 +0200 [thread overview]
Message-ID: <20020827142004.C4358@wotan.suse.de> (raw)
In-Reply-To: <Pine.GSO.4.30.0208270803520.6895-100000@shell.cyberus.ca>
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
next prev parent reply other threads:[~2002-08-27 12:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-25 15:56 packet re-ordering on SMP machines jamal
2002-08-25 18:32 ` Ben Greear
2002-08-26 0:52 ` jamal
2002-08-26 4:34 ` Ben Greear
2002-08-26 11:20 ` jamal
2002-08-26 23:03 ` Xiaoliang (David) Wei
2002-08-26 23:20 ` Ben Greear
2002-08-27 10:59 ` jamal
2002-08-27 11:12 ` Andi Kleen
2002-08-27 12:05 ` jamal
2002-08-27 12:20 ` Andi Kleen [this message]
2002-08-27 13:06 ` kuznet
2002-08-27 13:13 ` Andi Kleen
2002-08-27 13:24 ` kuznet
2002-09-15 8:42 ` Harald Welte
2002-09-15 21:55 ` Alexey Kuznetsov
2002-08-27 17:22 ` Cheng Jin
2002-08-27 17:33 ` Andi Kleen
2002-08-27 19:43 ` Xiaoliang (David) Wei
-- strict thread matches above, loose matches on Subject: below --
2002-08-25 15:56 jamal
2002-08-25 8:01 Manfred Spraul
2002-08-25 7:18 Ben Greear
2002-08-25 7:07 ` David S. Miller
2002-08-25 14:41 ` Alan Cox
2002-08-25 17:00 ` Ben Greear
2002-08-25 20:44 ` Alan Cox
2002-08-25 22:49 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020827142004.C4358@wotan.suse.de \
--to=ak@suse.de \
--cc=chenghu@cs.caltech.edu \
--cc=chengjin@cs.caltech.edu \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
--cc=slow@cs.caltech.edu \
--cc=weixl@caltech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.