On Sun, Nov 18, 2001 at 06:26:20PM -0800, Adam Prewett wrote:
> I am modifying the linux kernel to timestamp packets with the
> cycle counter rather than using its current xtime-scheme.
What version of the kernel?
For outgoing packets, it's done in "dev_queue_xmit_nit()", as you've
discovered.
For *incoming* packets, it's set in "netif_rx()", in most cases. Some
ATM drivers appear to set it themselves.
In both "dev_queue_xmit_nit()" and "netif_rx()", it uses
"get_fast_time()", at least in the 2.4.9 kernel; the ATM drivers set it
from "xtime" (I have no idea why), which will, at least as I read
"netif_rx()", keep "netif_rx()" from setting it with "get_fast_time()".
It looks as if, on x86, "get_fast_time()" will use the time stamp
counter if it's present and your kernel is configured for it
(CONFIG_X86_TSC), so it won't use xtime, by itself, to time stamp
packets, it'll use the time stamp counter as well.
If you're on some non-x86 platform, you might want to check whether
"get_fast_time()" is using any native high-resolution timer and, if not,
ask the developers of the kernel for that platform why not. That would
mean that time stamps all *over* the place in the kernel, not just
packet time stamps, would use the high-resolution timer.
I.e., it's not clear that, on machines with high-resolution-timing
hardware, it uses only xtime, by itself; it *should* use the
high-resolution-timing hardware, and appears to do so on x86, at least
if you've configured time stamp counter support in. (On other
platforms, determining whether it uses the high-resolution timer or not,
determining what you have to do to configure it to do so, and fixing it
so that it does so if there's currently no support for that in the
kernel, is left as an exercise for the reader.)
> I am modifying
> it to work with a program using the libpcap library. Anyways, I stamp
> my incoming packets at the device driver level and I am wondering how
> far down in the kernel can I stamp my outgoing packets and still be
> able to read the new values using the pcap library, I tried the
> driver, but that was too far down. I am currently
> doing it in dev_queue_xmit_nit in core.c but was trying to push it even
> farther down.
Libpcap, on Linux, reads the packet's time stamp with an SIOCGSTAMP
"ioctl" on the PF_PACKET socket from which it reads the packets.
That time stamp comes from the "stamp" field of the socket, which, in
turn, is set by the "sock_recv_timestamp()" function in
"include/net/sock.h", which sets it from the "stamp" field of the
sk_buff for the packet being received at the time the packet is read by
whatever software is reading it.
If you want to push the time stamps for outgoing packets lower, you may
find that there's no place lower to push them than
"dev_queue_xmit_nit()", as that's the point where outgoing packets get
wrapped around. It looks as if it clones the sk_buff, so any code below
that point that time stamps packets may time stamp the copy to be
transmitted, *not* the copy that's been wrapped around.
I'd suggest asking the linux-net list for further help.
; you could, I guess, put it in place of the
"sock_recv_timestamp()"
> I was wondering if someone could tell me where pcap captures them
> so I can read the counter right before that
What do you mean "where pcap captures them"?
libpcap doesn't, itself, capture packets; it just reads packets queued
up on its PF_PACKET socket.
For outgoing packets, the only things I can see "where pcap captures
them" meaning would be
1) the point at which the packet is wrapped around, which is
"dev_queue_xmit_nit()"
or
2) the point at which it *reads* the packet, which I'd consider
Too Late - especially for *incoming* packets (you'd have to
hack the "net/packet/af_packet.c" code - and do it in such a
way that only outgoing packets get a new time stamp).
As per the above, it doesn't look as if you *can* time stamp them at the
point the packet is put onto the wire, but I'd suggest asking linux-net
about that.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
