cvs commit: src/sys/net bpf.c

Jung-uk Kim jkim at FreeBSD.org
Tue Jul 25 16:13:37 UTC 2006


On Monday 24 July 2006 08:52 pm, Sam Leffler wrote:
> 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.

Yes, we can do that but I see at least two immediate problems.  First 
we still call microtime(9) from catchpacket() (or from bpf_mtap2(9) 
now) because bpf does not know anything about this *special* header.  
It surely beats the purpose.  Second, libpcap has to be modified to 
understand the header format and the trace will be incompatible with 
old apps.  AFAIK, this means they have to introduce another DLT for 
each supported DLT just because we added the timestamp, which is 
impractical IMHO.  Basically I want something more generic. :-)

Jung-uk Kim


More information about the cvs-all mailing list