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
next 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).