From owner-cvs-src@FreeBSD.ORG Tue Jul 25 00:52:12 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79F4616A4E0; Tue, 25 Jul 2006 00:52:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79BCC43D49; Tue, 25 Jul 2006 00:52:11 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6P0q8c2075792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jul 2006 17:52:10 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C56B38.4060706@errno.com> Date: Mon, 24 Jul 2006 17:52:08 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: Jung-uk Kim References: <200607241838.aa38962@salmon.maths.tcd.ie> <200607242046.12783.jkim@FreeBSD.org> In-Reply-To: <200607242046.12783.jkim@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Malone , cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Christian S.J. Peron" , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net bpf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 00:52:12 -0000 Jung-uk Kim wrote: > On Monday 24 July 2006 01:38 pm, David Malone wrote: >>> Thanks for taking care of this! It is not very desirable for the >>> same packet to have different timestamps associated with it >>> across different bpf peers. It certainly could cause a problem if >>> people are using timestamps to correlate events from different >>> programs on the same system. >> Indeed - calling microtime more than necessary and generating >> inconsistent timestamps just didn't seem good. >> >> I think jkim@ has interesting work related to this that might allow >> us to exploit hardware that does hardware timestamping of packets. >> It is some way down the road though. > > Darn, I guess I have to finish the work now since you said it. ;-) > The idea is simply to pass timeval to bpf_tap() from network drivers > when it is available and bpf is attached. (Something like > bpf_*tap_ts()?) Additionally we may add an ioctl for bpf to select > timestamping method, e.g., microtime(9), getmicrotime(9), > timestamping from lower layer, or no timestamping at all because we > don't need (accurate) timestamps in many places. For the > hardware-based accurate timestamping, the big challenge is actually > timecounter to timeval conversion, not the bpf API itself because we > can only select one hardware timecounter at a given time if the > controller does not give us timeval, bintime, or something similar. > We have to come up with some API to register additional timecounter, > which is not primary timecounter but synchronized with system uptime. > On top of that, the timecounter in the given descriptor is not > current timecounter. So we need 'what time was it then', not 'what > time is it now.' Why not leverage something like radiotap? It already has a mechanism for associating a 64-bit microsecond timestamp w/ each packet. It's presently somewhat wireless-oriented but could be used w/ wired devices too and tools like ethereal and tcpdump already grok it. Sam