All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Chad Reese <kreese@caviumnetworks.com>
Cc: Willem de Bruijn <willemb@google.com>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	David Daney <david.daney@cavium.com>
Subject: Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct
Date: Tue, 8 Jul 2014 11:41:18 +0200	[thread overview]
Message-ID: <20140708094118.GB6249@localhost.localdomain> (raw)
In-Reply-To: <53BBA0F6.3090003@caviumnetworks.com>

On Tue, Jul 08, 2014 at 12:42:46AM -0700, Chad Reese wrote:
> 
> You keep saying I implemented a clock servo in the MAC driver. I
> didn't, as is apparent in the code. The only kludge was a conversion
> from the PTP clock to system time with a simple offset function. I
> will fully admit it wasn't great, but it was good enough.

I assume that the point of providing both raw and sys time stamps was
to discipline the Linux system clock to the raw clock. (Otherwise, what
good are the sys values?)

In that case, the sample rate is a result of the packet activity in
the driver, and the rate is a part of the servo, at least to my
understanding.
 
> I wrote a PTPv2 daemon for Cavium that ran in userspace. It
> implemented all the v2 spec with support for both IP and 802.3
> transport. This was done from scratch as there wasn't an opensource
> PTPv2 daemon at the time. All this work actually started before
> there was any PTP timestamp support in the kernel. I originally
> started writing PTP to run on bare metal.

Okay, that is now clear. There is nothing wrong with that, although it
is too bad you cannot use the newer interface.

So, the question becomes, will removing the sys time stamp from the
octeon driver spoil your application?

[ The octeon time stamping was merged in August 2012, well after the
  PTP support which appeared in April 2011. So I guess that your
  custom application doesn't need the dual time stamps. ]

Thanks,
Richard

  reply	other threads:[~2014-07-08  9:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-03 19:39 net-timestamp: MSG_TSTAMP flags and bytestream support Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct Willem de Bruijn
2014-07-05 20:10   ` Richard Cochran
2014-07-18 15:54     ` Willem de Bruijn
2014-07-05 20:18   ` Richard Cochran
2014-07-07 15:34     ` Willem de Bruijn
2014-07-07 18:47       ` Richard Cochran
2014-07-07 19:14         ` Willem de Bruijn
2014-07-07 19:44           ` Chad Reese
2014-07-07 20:11             ` Richard Cochran
2014-07-07 21:03               ` Chad Reese
2014-07-08  6:04                 ` Richard Cochran
2014-07-08  7:42                   ` Chad Reese
2014-07-08  9:41                     ` Richard Cochran [this message]
2014-07-10 15:36                       ` Willem de Bruijn
2014-07-07 20:18             ` Richard Cochran
2014-07-07 21:08               ` Chad Reese
2014-07-08  5:49                 ` Richard Cochran
2014-07-08  6:08                   ` Richard Cochran
2014-07-03 19:39 ` [PATCH net-next v2 2/8] net-timestamp: MSG_TSTAMP one-shot tx timestamps Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 3/8] net-timestamp: tx timestamp without payload Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 4/8] net-timestamp: TCP timestamping Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 5/8] net-timestamp: ACK timestamp for bytestreams Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 6/8] net-timestamp: ENQ timestamp on enqueue to traffic shaping layer Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 7/8] net-timestamp: expand documentation Willem de Bruijn
2014-07-05 20:14   ` Richard Cochran
2014-07-07 15:40     ` Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 8/8] net-timestamp: SOCK_RAW and PING timestamping Willem de Bruijn

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=20140708094118.GB6249@localhost.localdomain \
    --to=richardcochran@gmail.com \
    --cc=davem@davemloft.net \
    --cc=david.daney@cavium.com \
    --cc=eric.dumazet@gmail.com \
    --cc=kreese@caviumnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=willemb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.