cvs commit: src/sys/net bpf.c
Sam Leffler
sam at errno.com
Tue Jul 25 00:52:12 UTC 2006
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
More information about the cvs-src
mailing list