netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ricardo Biehl Pasquali <pasqualirb@gmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net
Subject: [RFC] net: Allow setting clock type for network timestamps
Date: Tue, 11 Dec 2018 13:17:23 -0200	[thread overview]
Message-ID: <20181211151723.GA5965@localhost.localdomain> (raw)

Network timestamps are always from REALTIME clock, which
may be adjusted by the user (mainly Network Time Protocol
corrections though).

For applications that do not want this behavior, an option
for setting clock type is needed.

The sound subsystem has already an option to set the clock
type for its timestamps. See SNDRV_PCM_TSTAMP_TYPE_* in
include/uapi/sound/asound.h and snd_pcm_gettime() in
include/sound/pcm.h .

While preparing a small set of changes I found some issues.

Brief of the changes:

- Add SO_TIMESTAMP_CLOCK socket option macro.

- Add macros for clock types:
	SOF_TIMESTAMP_CLOCK_REALTIME,
	SOF_TIMESTAMP_CLOCK_MONOTONIC,
	SOF_TIMESTAMP_CLOCK_MONOTONIC_RAW,

- Add set/get for the option. Initialize to REALTIME.

- In __net_timestamp(), get the time according to
  sk_timestamp_clock in 'struct sock'.

Here "CLOCK" is used instead of "TYPE" to avoid confusion
with receive/transmit, hardware/software options.

Issues:

- Are there problems or security issues that may arise if
  changing the clock in __net_timestamp()?

- __net_timestamp() has no access to 'struct sock'. One
  alternative is move it from linux/skbuff.h to net/sock.h

- Do every caller of __net_timestamp() has skb->sk set?

  If adding 'struct sock*' as argument to
  __net_timestamp(struct sk_buff*), in places like
  net/ipv6/exthdrs.c ipv6_dest_hao(), skb->sk must be set
  anyway. (see next)

- Should __net_timestamp() be used in __skb_tstamp_tx()?

  In __skb_tstamp_tx(), for example, skb->sk would not have
  been set at the moment of __net_timestamp() call. It is
  set in sock_queue_err_skb(), called inside
  __skb_complete_tx_timestamp().

In short, there must be a function which has access to
'struct sk_buff' and 'struct sock' and can safely set any
clock type. At the same time that this should keep the
code as simple as possible.

Non-implementation issues:

- Code and macro duplication existing in multiple
  subsystems that set clock type.

  The sound have SNDRV_PCM_TSTAMP_TYPE_* + snd_pcm_gettime()
  and the network SOF_TIMESTAMP_CLOCK_* + __net_timestamp().
  This is somewhat similar to the NONBLOCK flag (e.g.
  TFD_NONBLOCK, EFD_NONBLOCK), however both point to
  O_NONBLOCK. Could this be improved?

  What about using CLOCK_* macros? Note that the sound
  subsystem is not using them, otherwise this may break
  Application Binary Interface.

- Rename __net_timestamp() to skb_timestamp() or something
  more clear/specific and perhaps similar to other parts of
  the kernel.

	pasquali

             reply	other threads:[~2018-12-11 15:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 15:17 Ricardo Biehl Pasquali [this message]
2018-12-12 16:15 ` [RFC] net: Allow setting clock type for network timestamps 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=20181211151723.GA5965@localhost.localdomain \
    --to=pasqualirb@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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 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).