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: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.4.30.0208251149320.29461-100000@shell.cyberus.ca>
2002-08-25 18:32 ` packet re-ordering on SMP machines 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
2002-08-25 15:56 jamal
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).