All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Lichvar <mlichvar@redhat.com>
To: sdncurious <sdncurious@gmail.com>
Cc: netdev@vger.kernel.org,
	Richard Cochran <richardcochran@gmail.com>,
	Jiri Benc <jbenc@redhat.com>,
	"Keller, Jacob E" <jacob.e.keller@intel.com>,
	Denny Page <dennypage@me.com>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: Extending socket timestamping API for NTP
Date: Wed, 8 Feb 2017 11:26:23 +0100	[thread overview]
Message-ID: <20170208102623.GC11233@localhost> (raw)
In-Reply-To: <CAHoNx59VwLbACPp_3a5doyi=Y1hUqU5oVvJqxpsv777W2g+Z8w@mail.gmail.com>

On Tue, Feb 07, 2017 at 12:37:15PM -0800, sdncurious wrote:
> On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps
> >
> >    With bridges, bonding and other things it's difficult to determine
> >    which PHC timestamped the packet. It would be very useful if the
> >    PHC index was provided with each HW timestamp.
> >
> >    I'm not sure what would be the best place to put it. I guess the
> >    second timespec in scm_timestamping could be reused for this, but
> >    that sounds like a gross hack. Do we need to define a new struct?
> 
> What is the use case for this. even if the delay though the PHY's how
> would that be compensated ?

The idea was that applications like NTP servers and clients wouldn't
have to care about interfaces and how they map together with addresses
to PHCs over time. Currently, I use the interface index from
IP_PKTINFO to get the PHC, but that doesn't work with bridges and
other virtual interfaces. Another possibility would be an option to
modify the behavior of IP_PKTINFO to save the index of the real
interface. I'm not sure how would that compare in difficulty to
extending SCM_TIMESTAMPING with PHC index.

-- 
Miroslav Lichvar

  reply	other threads:[~2017-02-08 10:38 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 14:01 Extending socket timestamping API for NTP Miroslav Lichvar
2017-02-07 17:45 ` Keller, Jacob E
2017-02-07 22:32   ` Willem de Bruijn
2017-02-08 14:18     ` Soheil Hassas Yeganeh
2017-02-27 15:23     ` Miroslav Lichvar
2017-02-28  0:01       ` Willem de Bruijn
2017-02-28  8:26         ` Miroslav Lichvar
2017-02-28 21:05           ` Willem de Bruijn
2017-02-08  1:52   ` Denny Page
2017-02-08  5:27     ` Richard Cochran
2017-02-08  5:48       ` Denny Page
2017-02-08 17:27       ` Denny Page
2017-02-07 18:54 ` Soheil Hassas Yeganeh
2017-02-08 10:14   ` Miroslav Lichvar
2017-02-07 20:37 ` sdncurious
2017-02-08 10:26   ` Miroslav Lichvar [this message]
2017-02-08 23:27     ` sdncurious
2017-02-08 23:34     ` sdncurious
2017-02-08  1:18 ` Denny Page
     [not found] ` <CAHoNx58u=Fze4e5V2Wb_LiBhka1Mzny3zOVNfvuzjnmQ4wBO=Q@mail.gmail.com>
2017-02-08  3:06   ` Denny Page
2017-02-09  0:45 ` Denny Page
2017-02-09 11:15   ` Miroslav Lichvar
2017-02-09 20:25   ` Denny Page
2017-02-09  8:02 ` Richard Cochran
2017-02-09 11:09   ` Miroslav Lichvar
2017-02-09 19:42     ` sdncurious
2017-02-09 20:37       ` Denny Page
2017-02-10  0:33       ` Denny Page
2017-02-10 18:55         ` Denny Page
2017-03-23 16:21     ` Miroslav Lichvar
2017-03-23 18:54       ` Denny Page
2017-03-23 19:07       ` Richard Cochran
2017-03-24  7:25         ` Miroslav Lichvar
     [not found]       ` <6121D504-288F-4C9B-9AB3-D1C8292965D5@me.com>
2017-03-24  9:45         ` Miroslav Lichvar
2017-03-24 17:17           ` Denny Page
2017-03-24 18:52             ` Keller, Jacob E
2017-03-27 10:13             ` Miroslav Lichvar
2017-03-27 14:29               ` Richard Cochran
2017-03-27 16:25                 ` Denny Page
2017-03-27 18:28                   ` Richard Cochran
2017-03-27 19:18                     ` Denny Page
2017-03-27 20:58                       ` Richard Cochran
2017-03-27 21:20                         ` Denny Page
2017-03-27 19:21                     ` Denny Page
2017-03-27 19:21                     ` Denny Page
     [not found]                     ` <5FD283AB-39DE-4A9D-902A-BA5F0F0B62A3@me.com>
2017-03-27 21:00                       ` Richard Cochran
2017-03-24  9:55         ` Jiri Benc

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=20170208102623.GC11233@localhost \
    --to=mlichvar@redhat.com \
    --cc=dennypage@me.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jbenc@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=sdncurious@gmail.com \
    --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.