Date: Mon, 24 Jul 2006 17:52:08 -0700 From: Sam Leffler <sam@errno.com> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: David Malone <dwmalone@maths.tcd.ie>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Christian S.J. Peron" <csjp@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net bpf.c Message-ID: <44C56B38.4060706@errno.com> In-Reply-To: <200607242046.12783.jkim@FreeBSD.org> References: <200607241838.aa38962@salmon.maths.tcd.ie> <200607242046.12783.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jung-uk Kim wrote: > On Monday 24 July 2006 01:38 pm, David Malone wrote: >>> Thanks for taking care of this! It is not very desirable for the >>> same packet to have different timestamps associated with it >>> across different bpf peers. It certainly could cause a problem if >>> people are using timestamps to correlate events from different >>> programs on the same system. >> Indeed - calling microtime more than necessary and generating >> inconsistent timestamps just didn't seem good. >> >> I think jkim@ has interesting work related to this that might allow >> us to exploit hardware that does hardware timestamping of packets. >> It is some way down the road though. > > Darn, I guess I have to finish the work now since you said it. ;-) > The idea is simply to pass timeval to bpf_tap() from network drivers > when it is available and bpf is attached. (Something like > bpf_*tap_ts()?) Additionally we may add an ioctl for bpf to select > timestamping method, e.g., microtime(9), getmicrotime(9), > timestamping from lower layer, or no timestamping at all because we > don't need (accurate) timestamps in many places. For the > hardware-based accurate timestamping, the big challenge is actually > timecounter to timeval conversion, not the bpf API itself because we > can only select one hardware timecounter at a given time if the > controller does not give us timeval, bintime, or something similar. > We have to come up with some API to register additional timecounter, > which is not primary timecounter but synchronized with system uptime. > On top of that, the timecounter in the given descriptor is not > current timecounter. So we need 'what time was it then', not 'what > time is it now.' Why not leverage something like radiotap? It already has a mechanism for associating a 64-bit microsecond timestamp w/ each packet. It's presently somewhat wireless-oriented but could be used w/ wired devices too and tools like ethereal and tcpdump already grok it. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C56B38.4060706>