All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemb@google.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Chad Reese <kreese@caviumnetworks.com>,
	David Daney <david.daney@cavium.com>
Subject: Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct
Date: Mon, 7 Jul 2014 15:14:41 -0400	[thread overview]
Message-ID: <CA+FuTSeqf=xgjjVreasKGZVPR1iXRKr68R7dj8n9w31-hUnznA@mail.gmail.com> (raw)
In-Reply-To: <20140707184700.GA1610@localhost.localdomain>

On Mon, Jul 7, 2014 at 2:47 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Mon, Jul 07, 2014 at 11:34:05AM -0400, Willem de Bruijn wrote:
>>
>> The hardware timestamp converted to system time is deprecated? I did
>> not know that. Because it is largely unused, or for a more fundamental
>> reason?
>
> It is for the fundamental reason that the idea behind it is just plain
> wrong. MAC drivers are not the place to put clock servos.
>
>> If so, the documentation could indeed use an explicit comment. The
>> definition of skb_shared_hwtstamps.syststamp too. I can write a small
>> patch independent of this patchset.
>
> Please do.

Ok. See below.

>
>> Unfortunately, a cursory inspection shows one, octeon. While that user
>> exists and generates such timestamps, I think that the above new flag
>> should be passed, as well, for API consistency.
>
> Ugh, how the heck did that turd get in? Its not like they bothered to
> include the maintainer on CC. That code must go.

I'm happy to unwind the syststamp part of 3d305850 ("netdev:
octeon_mgmt: Add hardware timestamp support"). Chad, let me know if
you object to that. Else, I'll send a patch to you both for review.

Once that is in, I'll follow up with a driver-independent stack patch
that removes the field in internal struct skb_shared_hwtstamps and
documents the legacy nature of the field in scm_timestamping. In
that case, we don't have to document the internal field in the interim.

>
> Thanks,
> Richard

  reply	other threads:[~2014-07-07 19:15 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 [this message]
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
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='CA+FuTSeqf=xgjjVreasKGZVPR1iXRKr68R7dj8n9w31-hUnznA@mail.gmail.com' \
    --to=willemb@google.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=richardcochran@gmail.com \
    --cc=stephen@networkplumber.org \
    /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.