From: Ben Greear <greearb@candelatech.com>
To: "David S. Miller" <davem@redhat.com>
Cc: ak@suse.de, linux-kernel@vger.kernel.org
Subject: Re: Fast timestamps
Date: Wed, 26 Nov 2003 17:57:36 -0800 [thread overview]
Message-ID: <3FC55A10.2040704@candelatech.com> (raw)
In-Reply-To: <20031126160129.32855a15.davem@redhat.com>
David S. Miller wrote:
> On Wed, 26 Nov 2003 15:41:52 -0800
> Ben Greear <greearb@candelatech.com> wrote:
>
>
>>I'll try to write up a patch that uses the TSC and lazy conversion
>>to timeval as soon as I get the rx-all and rx-fcs code happily
>>into the kernel....
>>
>>Assuming TSC is very fast and the conversion is accurate enough, I think
>>this can give good results....
>
>
> I'm amazed that you will be able to write a fast_timestamp
> implementation without even seeing the API I had specified
> to the various arch maintainers :-)
Well, I would only aim at x86, with generic code for the
rest of the architectures. The truth is, I'm sure others would
be better/faster at it than me, but we keep discussing it, and it
never gets done, so unless someone beats me to it, I'll take a stab
at it... Might be after Christmas though, busy December coming up!
I agree with your approach below. One thing I was thinking about:
is it possible that two threads ask for the timestamp of a single skb
concurrently? If so, we may need a lock if we want to cache the conversion
to gettimeofday units.... Of course, the case where multiple readers want
the timestamp for a single skb may be too rare to warrant caching...
Ben
>
> ====================
>
> But at the base I say we need three things:
>
> 1) Some kind of fast_timestamp_t, the property is that this stores
> enough information at time "T" such that at time "T + something"
> the fast_timestamp_t can be converted what the timeval was back at
> time "T".
>
> For networking, make skb->stamp into this type.
>
> 2) store_fast_timestamp(fast_timestamp_t *)
>
> For networking, change do_gettimeofday(&skb->stamp) into
> store_fast_timestamp(&skb->stamp)
>
> 3) fast_timestamp_to_timeval(arch_timestamp_t *, struct timeval *)
>
> For networking, change things that read the skb->stamp value
> into calls to fast_timestamp_to_timeval().
>
> It is defined that the timeval given by fast_timestamp_to_timeval()
> needs to be the same thing that do_gettimeofday() would have recorded
> at the time store_fast_timestamp() was called.
>
> Here is the default generic implementation that would go into
> asm-generic/faststamp.h:
>
> 1) fast_timestamp_t is struct timeval
> 2) store_fast_timestamp() is gettimeofday()
> 3) fast_timestamp_to_timeval() merely copies the fast_timestamp_t
> into the passed in timeval.
>
> And here is how an example implementation could work on sparc64:
>
> 1) fast_timestamp_t is a u64
>
> 2) store_fast_timestamp() reads the cpu cycle counter
>
> 3) fast_timestamp_to_timeval() records the difference between the
> current cpu cycle counter and the one recorded, it takes a sample
> of the current xtime value and adjusts it accordingly to account
> for the cpu cycle counter difference.
>
> This only works because sparc64's cpu cycle counters are synchronized
> across all cpus, they increase monotonically, and are guarenteed not
> to overflow for at least 10 years.
>
> Alpha, for example, cannot do it this way because it's cpu cycle counter
> register overflows too quickly to be useful.
>
> Platforms with inter-cpu TSC synchronization issues will have some
> troubles doing the same trick too, because one must handle properly
> the case where the fast timestamp is converted to a timeval on a different
> cpu on which the fast timestamp was recorded.
>
> Regardless, we could put the infrastructure in there now and arch folks
> can work on implementations. The generic implementation code, which is
> what everyone will end up with at first, will cancel out to what we have
> currently.
>
> This is a pretty powerful idea that could be applied to other places,
> not just the networking.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2003-11-27 1:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BAY1-DAV15JU71pROHD000040e2@hotmail.com.suse.lists.linux.kernel>
[not found] ` <20031125183035.1c17185a.davem@redhat.com.suse.lists.linux.kernel>
2003-11-26 9:53 ` Fire Engine?? Andi Kleen
2003-11-26 11:35 ` John Bradford
2003-11-26 18:50 ` Mike Fedyk
2003-11-26 19:19 ` Diego Calleja García
2003-11-26 19:59 ` Mike Fedyk
2003-11-27 3:54 ` Bill Huey
2003-11-26 15:00 ` Trond Myklebust
2003-11-26 23:01 ` Andi Kleen
2003-11-26 23:23 ` Trond Myklebust
2003-11-26 23:38 ` Andi Kleen
2003-11-26 19:30 ` David S. Miller
2003-11-26 19:58 ` Paul Menage
2003-11-26 20:03 ` David S. Miller
2003-11-26 22:29 ` Andi Kleen
2003-11-26 22:36 ` David S. Miller
2003-11-26 22:56 ` Andi Kleen
2003-11-26 23:13 ` David S. Miller
2003-11-26 23:29 ` Andi Kleen
2003-11-26 23:41 ` Ben Greear
2003-11-27 0:01 ` Fast timestamps David S. Miller
2003-11-27 0:30 ` Mitchell Blank Jr
2003-11-27 1:57 ` Ben Greear [this message]
2003-11-26 20:01 ` Fire Engine?? Jamie Lokier
2003-11-26 20:04 ` David S. Miller
2003-11-26 21:54 ` Pekka Pietikainen
2003-11-26 20:22 ` Theodore Ts'o
2003-11-26 21:02 ` David S. Miller
2003-11-26 21:24 ` Jamie Lokier
2003-11-26 21:38 ` David S. Miller
2003-11-26 23:43 ` Jamie Lokier
2003-11-26 21:34 ` Arjan van de Ven
2003-11-26 22:58 ` Andi Kleen
2003-11-27 12:16 ` Ingo Oeser
2003-11-26 22:39 ` Andi Kleen
2003-11-26 22:46 ` 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=3FC55A10.2040704@candelatech.com \
--to=greearb@candelatech.com \
--cc=ak@suse.de \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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).