[RFC] BPF timestamping

[Jung-uk Kim]

On Wednesday 09 June 2010 03:42 pm, Jung-uk Kim wrote:
> 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
                             ^^^^^^^^^^^^^^^^^^^^^^^
                        SIZEOF_BPF_HDR(struct bpf_xhdr)

Argh...

Jung-uk Kim

> 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...