From: Ingo Oeser <netdev@axxeo.de>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
Patrick Ohly <patrick.ohly@intel.com>,
netdev@vger.kernel.org
Subject: Re: [RFC][PATCH 1/1] net: support for hardware timestamping
Date: Tue, 29 Jul 2008 19:30:19 +0200 [thread overview]
Message-ID: <200807291930.20033.netdev@axxeo.de> (raw)
In-Reply-To: <200807291911.10364.opurdila@ixiacom.com>
Hi Octavian,
Octavian Purdila schrieb:
> On Tuesday 29 July 2008, Stephen Hemminger wrote:
> >
> > In my sky2 sample code, I took a different approach:
> > 1. Why have HW timestamps different than existing timestamps? If you
> > just use existing timestamp, no socket API is needed.
>
> I agree that is a much better approach if you are ok with the variance
> introduced by synchronizing the HW timestamps with the CPU clock.
Just convert your hardware specific cookie you have into the nanoseconds
resolution timstamp in skb->tstamp just before calling netif_rx()
or net_receive_skb().
These functions will not touch it, as long as they never see a ZERO
value there. A ZERO value in tstamp.tv64 means, we have no timestamp.
The difference to CPU clock doesn't matter.
That compensation can be done by your driver or application at will.
For mainline, compensation in driver might be preferred.
As long as it is montonic increasing and related to time in any way,
you could put anything there, I think :-)
The timestamp in nanoseconds will be submitted as CMSG().
see net/socket.c "put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPNS, sizeof(ts), &ts);"
Enable it with this code fragment in user space:
int one = 1;
setsockopt(mysok, SOL_SOCKET, SO_TIMESTAMPNS, &one);
In the kernel the call chain is: raw_recvmsg() -> sock_recv_timestamp() -> __sock_recv_timestamp()
__sock_recv_timestamp() is:
void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
struct sk_buff *skb)
{
ktime_t kt = skb->tstamp;
if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Check for nanosecond timestamps
struct timeval tv;
/* Race occurred between timestamp enabling and packet
receiving. Fill in the current time for now. */
if (kt.tv64 == 0)
kt = ktime_get_real();
skb->tstamp = kt;
tv = ktime_to_timeval(kt);
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMP, sizeof(tv), &tv);
} else {
struct timespec ts;
/* Race occurred between timestamp enabling and packet
receiving. Fill in the current time for now. */
if (kt.tv64 == 0)
kt = ktime_get_real();
skb->tstamp = kt;
ts = ktime_to_timespec(kt);
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPNS, sizeof(ts), &ts);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Put nanosecond timestamps into CMSG()
}
}
> But if you want to precisely measure one-way delays, and if you have the hw
> timestamp units synchronized across the nodes, then you need the hardware
> timesetamp.
Yes, no argument against that. Just your new user space ABI is simply not
required for RX timestamps. It works out of the box already.
Best Regards
Ingo Oeser
next prev parent reply other threads:[~2008-07-29 17:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 0:07 [RFC][PATCH 0/1] net: support for hardware timestamps Octavian Purdila
2008-07-29 0:08 ` [RFC][PATCH 1/1] net: support for hardware timestamping Octavian Purdila
2008-07-29 14:52 ` Patrick Ohly
2008-07-29 15:49 ` Octavian Purdila
2008-07-30 9:35 ` Patrick Ohly
2008-07-30 13:38 ` Octavian Purdila
2008-07-30 14:00 ` Patrick Ohly
2008-07-29 15:54 ` Stephen Hemminger
2008-07-29 16:11 ` Octavian Purdila
2008-07-29 17:30 ` Ingo Oeser [this message]
2008-07-29 18:10 ` Octavian Purdila
2008-07-29 18:27 ` Ingo Oeser
2008-07-30 8:51 ` Patrick Ohly
2008-07-30 9:34 ` Ingo Oeser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200807291930.20033.netdev@axxeo.de \
--to=netdev@axxeo.de \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
--cc=patrick.ohly@intel.com \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).