Date: Wed, 9 Jun 2010 15:42:35 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping Message-ID: <201006091542.37681.jkim@FreeBSD.org> In-Reply-To: <20100609191651.GR83316@deviant.kiev.zoral.com.ua> References: <201006091444.50560.jkim@FreeBSD.org> <20100609191651.GR83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006091542.37681.jkim>