From owner-cvs-all@FreeBSD.ORG Tue Jul 25 00:46:36 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCFE16A4DD; Tue, 25 Jul 2006 00:46:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3413A43D49; Tue, 25 Jul 2006 00:46:32 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k6P0kWTr069859; Mon, 24 Jul 2006 20:46:32 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: David Malone Date: Mon, 24 Jul 2006 20:46:02 -0400 User-Agent: KMail/1.6.2 References: <200607241838.aa38962@salmon.maths.tcd.ie> In-Reply-To: <200607241838.aa38962@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607242046.12783.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1616/Mon Jul 24 13:49:29 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 00:46:36 -0000 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.' Jung-uk Kim