[RFC] BPF timestamping

[Jung-uk Kim]

On Wednesday 09 June 2010 03:16 pm, Kostik Belousov wrote:
> On Wed, Jun 09, 2010 at 02:44:47PM -0400, 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
> >
> > (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.)
> >
> > 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.
>
> Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange.

If we burn bridges, we don't need to convert 64-bit bh_tstamp to 
32-bit version because the sizeof(struct bpf_xhdr) is fixed for both 
32-bit and 64-bit platforms.  The only difference is alignment and 
padding because of the evil u_short bh_hdrlen.  So, it was necessary 
evil if we don't want to break ABI between old 32-bit appliacations 
and bridge-burned 64-bit kernel.

No, we are not going to burn bridges any time soon unless libpcap 
adopt the new structure.  Shrug...

Jung-uk Kim