From owner-freebsd-net Sun Oct 25 14:20:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22723 for freebsd-net-outgoing; Sun, 25 Oct 1998 14:20:32 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22718 for ; Sun, 25 Oct 1998 14:20:31 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id RAA10102 for ; Sun, 25 Oct 1998 17:19:57 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199810252219.RAA10102@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-net@FreeBSD.ORG From: "Louis A. Mamakos" Subject: questions of taste.. mbuf header change Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Oct 1998 17:19:56 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm working on a project which is going to use FreeBSD 3.0 based systems to do some precise (one-way) network delay measurements using to special hardware, GPS receivers and the like. Part of the mechanism to do this involves timestamping each packet as it's received from the network, and then passing this timestamp along much later on to a user-mode process; this is the easy part, and we can reuse some of the SO_TIMESTAMP changes that I submitted a year or so ago (and which we subsequently moved around a bit). The question of taste comes from the need to insert a struct timespec into the mbuf packet header. There are two issues here: - what, if anything, breaks if there are 8 or 10 bytes fewer space in the first mbuf? There was some discussion a while ago about increasing MSIZE from 128 to something larger, but this didn't seem to happen. - how to minimize header file dependencies by introducing a new data type. Should I add a #ifndef _SYS_TIME_H_ #include #endif in sys/mbuf.h? There seems to be a trade-off between the "right" thing and maintaining compatability, and I'm not sure what the correct approach is. I hoping someone else has suffered through this issue once before with some advice. I would eventually like to submit the changes back to the FreeBSD project, suitablye #ifdef'd for people that don't want to use them. Reading the clock on every packet might be expensive in some circumstances; for my application the clock hardware is just a few PCI bus cycles away.. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message