Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jun 2010 22:16:51 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Jung-uk Kim <jkim@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: [RFC] BPF timestamping
Message-ID:  <20100609191651.GR83316@deviant.kiev.zoral.com.ua>
In-Reply-To: <201006091444.50560.jkim@FreeBSD.org>
References:  <201006091444.50560.jkim@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--2TczCHLg+zehSNVj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> it to be able to use different format and resolution.  The patch is=20
> here:
>=20
> http://people.freebsd.org/~jkim/bpf_tstamp.diff
>=20
> With this patch, we can select different format and resolution of the=20
> timestamps.  It is done via ioctl(2) with BIOCSTSTAMP command. =20
> Similarly, you can get the current format and resolution with=20
> BIOCGTSTAMP command.  Currently, the following functions are=20
> available:
>=20
> 	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
>=20
> (Note: Additionally, there is an experimental machanism to tag packets=20
> with timestamps in struct bintime format via mbuf_tags(9) from lower=20
> layer, e.g., device driver.  However, I didn't test it because I=20
> wasn't sure whether this is the right thing to do.)
>=20
> While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c=20
> and tried to make it little bit more correct.  For example, the=20
> 32-bit shim should be able to handle alignment more properly for=20
> non-Ethernet DLTs.  I tried my best not to break ABI/API (especially=20
> for 32-bit platforms) and relevant places are all marked with=20
> BURN_BRIDGES.
Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange.

--2TczCHLg+zehSNVj
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkwP6KMACgkQC3+MBN1Mb4gMUgCggfGPETcl7pZMIGgEO2aQwiU1
vjEAoLBJwH1ZOgNDulSWZ1q1/umWXi71
=iYaM
-----END PGP SIGNATURE-----

--2TczCHLg+zehSNVj--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100609191651.GR83316>