From owner-svn-src-all@FreeBSD.ORG Mon Nov 28 03:59:08 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C861065672; Mon, 28 Nov 2011 03:59:08 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id 017678FC0A; Mon, 28 Nov 2011 03:59:07 +0000 (UTC) X-AuditID: 1209190c-b7f806d0000008d6-a1-4ed3070b1678 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B5.89.02262.B0703DE4; Sun, 27 Nov 2011 22:59:07 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pAS3x63v028384; Sun, 27 Nov 2011 22:59:06 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAS3x2Io002295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Nov 2011 22:59:05 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pAS3x1Pg026802; Sun, 27 Nov 2011 22:59:01 -0500 (EST) Date: Sun, 27 Nov 2011 22:59:01 -0500 (EST) From: Benjamin Kaduk To: Lawrence Stewart In-Reply-To: <4ECCA2A1.4020408@freebsd.org> Message-ID: References: <201111210417.pAL4HOdi023556@svn.freebsd.org> <648D11A8-3636-49E5-BF20-83E4EA87242C@cubinlab.ee.unimelb.edu.au> <4EC9FD8A.5040401@freebsd.org> <201111220830.05029.jhb@freebsd.org> <4ECBAB19.4010907@freebsd.org> <8805563E-60F9-4BF4-A292-1A43C4FA368A@cubinlab.ee.unimelb.edu.au> <4ECCA2A1.4020408@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1uVmv+xnMPGukMXeI9eZLaat38Vo sflWF7PFm5YfLBZ/2qcAiU0LWS2avixgcmD3aDjv4zHj03wWj52z7rIHMEdx2aSk5mSWpRbp 2yVwZfzcsZG1oFeyYveNSywNjG+Fuxg5OSQETCQWLPnFDmGLSVy4t54NxBYS2McoceKNexcj F5C9gVHiQ28TM4RzgEli3fQtrBBOA6PEm/vvWEFaWAS0JVbN3sIMYrMJqEjMfLMRbJQIUHzb 2c9gNcwC9xklNiwpA7GFBfQlvq6eyAJicwLVvJ9wmxHE5hWwl7i9ajvUtoNMEntaNzCBJEQF dCRW75/CAlEkKHFy5hMWiKGWEuf+XGebwCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJ eXmpRbqGermZJXqpKaWbGMFhLsmzg/HNQaVDjAIcjEo8vBsvX/ITYk0sK67MPcQoycGkJMrr wHLZT4gvKT+lMiOxOCO+qDQntfgQowQHs5IIb89RoHLelMTKqtSifJiUNAeLkjjvwR0OfkIC 6YklqdmpqQWpRTBZGQ4OJQneZDagoYJFqempFWmZOSUIaSYOTpDhPEDD/UBqeIsLEnOLM9Mh 8qcYFaXEee1BEgIgiYzSPLheWBp6xSgO9IowbyhIFQ8whcF1vwIazAQ0mGPmBZDBJYkIKakG xpLKwkOya/+35sXe4DMu5DHyvVHt07jjz78s4xuSMpl/yk8ql05baWLQ/cDBtzjzY9Fjx1un RPkfml9YfS+1PnZ524IX1V43j+W5MViLidulv5gb83JPxdGlv3In7zkati0kK3Tlk/qspFML pLbVRv0/Mf3clP+vMy/Z7HGdwBbHtUQ0wnFaqBJLcUaioRZzUXEiAKXaz+AeAwAA Cc: src-committers@freebsd.org, John Baldwin , svn-src-all@freebsd.org, Julien Ridoux , Ben Kaduk , svn-src-head@freebsd.org Subject: Re: svn commit: r227778 - head/sys/net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 03:59:08 -0000 On Wed, 23 Nov 2011, Lawrence Stewart wrote: > On 11/23/11 17:42, Julien Ridoux wrote: >> >> Thanks all for the feedback. With some delay, I have a patch against >> r227871 that implements what Lawrence proposed. You can find it >> here: >> http://www.cubinlab.ee.unimelb.edu.au/~jrid/patches/ffclock-bpf-header-r227871.patch > > There are a few nits, but the patch implements what I envisaged, thanks > Julien. The use of the union for bh_ustamp feels a bit odd, as (e.g.) a bpf_ts is two 64-bit ints, but an ffcounter is just a single 64-bit int. > >> I have tested this under a few typical scenario, it works as >> expected but already brings some headaches (hence the long delay >> mentioned above :-)). >> >> I thought a bit more of user cases. I believe many of them call for >> having both feed-forward counter and its conversion in second be >> present in the BPF header. For example, this allows to have absolute >> packet departure/arrival times (as per usual), but also provides the >> opportunity to compute inter-arrival times accurately using the >> difference clock. There are other examples I can think of, and if one >> believe the feed-forward clock approach becomes more popular, such >> usages will be more and more common. >> Having read only the first introductory link that Lawrence posted when he first started introducing the ffclock code, it does really seem like there are lots of interesting things to do with both timestamps available. >> Assuming the BPF header grows by 8 bytes independent of any kernel >> option, I admit that the current implementation is a bit ugly. The >> BPF structure is not nicely packed and looks clunky. Ideally, the The +#define bh_tstamp bh_ustamp.ts_stamp is a sort of thing that can get annoying when poking around kernel cores, &c. I won't argue with you that the current implementation is a bit ugly. >> feed-forward counter should be placed just below the bh_tstamp >> member, but this would require libpcap and all ports depending on it >> to be recompiled after this change. > > Even though it looks a bit gross, we would still add it at the end to avoid > gratuitously breaking binaries. We would then also add some explicit padding > in the struct to soak up the redundant space left in between it and the > second last struct member. Though ... we are just after a release branch is forked. That seems to be a much better time to change the ABI for cleanliness' sake than right before a release ;) > >> What is your favourite option? > > FreeBSD parlance is to ask what colour you would like to paint the bikeshed > ;) > > As I've never experienced the pain John refers to, I'll defer to the wisdom > of others on whether the proposed patch will create pain down the road. I > think it's ok, but if consensus is 8bytes per packet isn't going to break the > bank, I guess we just go for it - but I guess I am cautious about this route > as we can push a lot of packets per second through the stack. Since other people seem to be keeping quiet, I'll add that I'm in favor of just always adding the 8 bytes per packet. Thanks, -Ben Kaduk