From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 18:45:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 517691065673 for ; Wed, 9 Jun 2010 18:45:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Wed, 9 Jun 2010 14:44:47 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006091444.50560.jkim@FreeBSD.org> Cc: Subject: [RFC] BPF timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:45:01 -0000 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. What do you think? Is it worth committing? Thanks, Jung-uk Kim