Re: Extending socket timestamping API for NTP

[Miroslav Lichvar <mlichvar@redhat.com>]

On Tue, Feb 07, 2017 at 10:54:22AM -0800, Soheil Hassas Yeganeh wrote:
> On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > 2) new SO_TIMESTAMPING option to receive from the error queue only
> >    user data as was passed to sendmsg() instead of Ethernet frames
> >
> >    Parsing Ethernet and IP headers (especially IPv6 options) is not
> >    fun and SOF_TIMESTAMPING_OPT_ID is not always practical, e.g. in
> >    applications which process messages from the error queue
> >    asynchronously and don't bind/connect their sockets.
> 
> This is going to be quite useful. However, I'm not sure if sending
> back the original packet would be a proper API. Instead, one option is
> to add a control message, so that applications can set the OPT_ID for
> the timestamp. Perhaps, something like from user's perspective:
> 
> cmsg->cmsg_level             = SOL_SOCKET;
> cmsg->cmsg_type              = SCM_TIMESTAMPING_OPT_ID;
> cmsg->cmsg_len               = CMSG_LEN(sizeof(__u32));
> *((__u32 *) CMSG_DATA(cmsg)) = my_id;

That could be very useful. The question is if 32 bits worth of user
data would be good enough for all applications. In the case of the NTP
server, I currently save 128 bits per client in order to support the
interleaved mode. Half of that is the receive timestamp, which is
compared to the receive timestamp from messages received from the
error queue. Matching only lower 32 bits of the timestamp would
probably still work fine. However, if NTP supported follow up messages
like PTP, 32 bits would not be enough to create a valid message for
the client without saving some additional state. Getting the original
message would be very convenient here. NTP packets are normally very
short, so I'm not sure how much benefit there would be in using the
OPT_ID.

-- 
Miroslav Lichvar