[RFC] BPF timestamping

[Lawrence Stewart]

On 06/10/10 04:44, Jung-uk Kim wrote:
> bpf(4) can only timestamp packets with microtime(9).  I want to expand
> it to be able to use different format and resolution.  The patch is
> here:
>
> http://people.freebsd.org/~jkim/bpf_tstamp.diff
>
> With this patch, we can select different format and resolution of the
> timestamps.  It is done via ioctl(2) with BIOCSTSTAMP command.
> Similarly, you can get the current format and resolution with
> BIOCGTSTAMP command.  Currently, the following functions are
> available:
>
> 	BPF_T_MICROTIME		microtime(9)
> 	BPF_T_NANOTIME		nanotime(9)
> 	BPF_T_BINTIME		bintime(9)
> 	BPF_T_MICROTIME_FAST	getmicrotime(9)
> 	BPF_T_NANOTIME_FAST	getnanotime(9)
> 	BPF_T_BINTIME_FAST	getbintime(9)
> 	BPF_T_NONE		ignore time stamps

This sounds great, assuming it is extensible such that it's easy to add 
new methods in the future.

> (Note: Additionally, there is an experimental machanism to tag packets
> with timestamps in struct bintime format via mbuf_tags(9) from lower
> layer, e.g., device driver.  However, I didn't test it because I
> wasn't sure whether this is the right thing to do.)

This is also an important feature for newer NICs, but I'm also not sure 
if tags are the right way to do it. It certainly wouldn't be a bad way 
to start though.

> While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c
> and tried to make it little bit more correct.  For example, the
> 32-bit shim should be able to handle alignment more properly for
> non-Ethernet DLTs.  I tried my best not to break ABI/API (especially
> for 32-bit platforms) and relevant places are all marked with
> BURN_BRIDGES.
>
> What do you think?  Is it worth committing?

I won't comment on the actual patch, but the ideas described above get 
the thumbs up from me.

Cheers,
Lawrence