Messages in this thread | | | Date | Wed, 26 Nov 2003 17:57:36 -0800 | From | Ben Greear <> | Subject | Re: Fast timestamps |
| |
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
- 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/
| |