From: Mitchell Blank Jr <mitch@sfgoth.com>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: Re: do_gettimeofday
Date: Fri, 3 Oct 2003 01:26:42 -0700 [thread overview]
Message-ID: <20031003082642.GF42593@gaz.sfgoth.com> (raw)
In-Reply-To: <20031003004133.3148c39a.davem@redhat.com>
David S. Miller wrote:
> 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().
Are there any common cases where skb->stamp is looked at more than
once? If so I might recommend changing the API to be more like:
const struct timeval *skb_timestamp(struct skbuff *skb);
where the generic form would just be:
typedef struct {
struct timeval tv;
} fast_timestamp_t;
static inline const struct timeval *skb_timestamp(struct skbuff *skb) {
return &skb->faststamp.tv;
}
...but an arch could accelerate it with:
typedef struct {
union {
struct timeval tv;
u64 tsc;
}
int is_converted;
} fast_timestamp_t;
/* Caller must be sure we have exclusive ownership of this skbuff */
const struct timeval *skb_timestamp(struct skbuff *skb) {
if (!skb->faststamp.is_converted) {
tsc_to_timeval(&skb->faststamp.tv, skb->faststamp.tsc);
skb->faststamp.is_converted = 1;
}
return &skb->faststamp.tv;
}
If we could hide "is_converted" as a flag somewhere else this would have zero
storage penalty (since most archs would have a fast-stamp at least
as big as a timeval)
I dunno, just an idea.
> 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.
Yeah, you'd probably have something like
typedef struct {
union {
struct timeval tv;
struct {
u64 tsc;
#ifdef CONFIG_SMP
unsigned int cpu_id;
#endif /* CONFIG_SMP */
} fast;
}
int is_converted;
} fast_timestamp_t;
And then skb_timestamp() would have to rummage around in the per-cpu timer
state for whatever processor started the packet. (This is why I thought
it might be good to cache the result - you don't want to thrash those
cachelines more than once if you can help it)
-Mitch
next prev parent reply other threads:[~2003-10-03 8:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-02 18:32 do_gettimeofday Steve Modica
2003-10-02 19:29 ` do_gettimeofday Andi Kleen
2003-10-02 19:56 ` do_gettimeofday Stephen Hemminger
2003-10-02 20:46 ` do_gettimeofday Mitchell Blank Jr
2003-10-03 7:41 ` do_gettimeofday David S. Miller
2003-10-03 8:26 ` Mitchell Blank Jr [this message]
2003-10-03 8:27 ` do_gettimeofday David S. Miller
2003-10-03 8:48 ` do_gettimeofday Mitchell Blank Jr
2003-10-03 8:52 ` do_gettimeofday David S. Miller
2003-10-03 9:26 ` do_gettimeofday Mitchell Blank Jr
2003-10-03 9:23 ` do_gettimeofday David S. Miller
2003-10-03 16:42 ` do_gettimeofday Ben Greear
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=20031003082642.GF42593@gaz.sfgoth.com \
--to=mitch@sfgoth.com \
--cc=davem@redhat.com \
--cc=netdev@oss.sgi.com \
/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).