net-timestamp: MSG_TSTAMP flags and bytestream support

net-timestamp: MSG_TSTAMP flags and bytestream support

[Willem de Bruijn]

This patchset extends socket timestamping for continuous sampled
monitoring of a wider set of protocols, including discrete
messages layered over bytestreams.

Patches 5 and 6 add additional measurement points in the data
lifecycle, to be able to detect the cause of latency (e.g.,
which tc queue).

Patch 4 extends timestamping to bytestreams, because many
application protocols, including those with discrete payloads,
use TCP as a transport layer for reliability, flow control, etc.

Patch 2 adds a send() flag-based control interface to request a
timestamp for a payload. With bytestream-based timestamping, this
allows an application to communicate the boundaries of discrete
application payloads, which often span multiple send() calls.

A second use of this feature is in sampled background monitoring.
For high volume production server workloads, high sampling rates
may be the only feasible approach to 24/7 monitoring.

The other patches support these core features:

Patch 1 explicitly defines a previously implicitly defined struct
Patch 3 optionally conserves SO_SNDBUF by not looping payloads
        back onto the error queue
Patch 7 documents the new mechanisms
Patch 8 fixes SO_TIMESTAMPING for SOCK_RAW and ping sockets
        and adds support for the new MSG_TSTAMP interface.

The individual patch commit messages gives more detail about the
specific feature.

Changelog:
  v1->v2
  - expand timestamping (existing and new) to SOCK_RAW and ping sockets
  - rename sock_errqueue_timestamping to scm_timestamping
  - change timestamp data format: do not add fields to scm_timestamping.
      Doing so could break legacy applications. Instead, communicate
      through an existing, but unused, field in the error message.
  - rename SOF_.._OPT_TX_NO_PAYLOAD to shorter SOF_.._OPT_TSONLY
  - move msg_tstamp test app out of patchset and to github
      git://github.com/wdebruij/kerneltools.git
 
Tested:
  msg_tstamp with various settings:
  - IPv4 and IPv6
  - UDP and TCP
  - 1 B and 20 KB payload
  - GSO, TSO, neither
  - with and without the no-payload feature (patch 3)

  Example output from one IPv4/TCP/1B/payload run:
  (on a bonded machine, resulting in 2 ENQ timestamps per send)

proto INET
  test SND
      USR: 1400265321 s 167847 us (seq=0, len=0)
      SND: 1400265321 s 167854 us (seq=408779523, len=7)  (+7 us)
  test ENQ
      USR: 1400265321 s 768728 us (seq=0, len=7)
      ENQ: 1400265321 s 768732 us (seq=3113669987, len=7)  (+4 us)
      ENQ: 1400265321 s 768734 us (seq=3113669987, len=7)  (+2 us)
  test ENQ + SND
      USR: 1400265322 s 369747 us (seq=0, len=7)
      ENQ: 1400265322 s 369750 us (seq=2305548511, len=7)  (+3 us)
      ENQ: 1400265322 s 369751 us (seq=2305548511, len=7)  (+1 us)
      SND: 1400265322 s 369752 us (seq=2305548511, len=7)  (+1 us)
  test ACK
      USR: 1400265322 s 970717 us (seq=0, len=7)
      ACK: 1400265322 s 970752 us (seq=2324323855, len=7)  (+35 us)
  test SND + ACK
      USR: 1400265323 s 571662 us (seq=0, len=7)
      SND: 1400265323 s 571681 us (seq=872301729, len=7)  (+19 us)
      ACK: 1400265323 s 571708 us (seq=872301729, len=7)  (+27 us)
  test ENQ + SND + ACK
      USR: 1400265324 s 172558 us (seq=0, len=7)
      ENQ: 1400265324 s 172561 us (seq=2135092223, len=7)  (+3 us)
      ENQ: 1400265324 s 172565 us (seq=2135092223, len=7)  (+4 us)
      SND: 1400265324 s 172581 us (seq=2135092223, len=7)  (+16 us)
      ACK: 1400265324 s 172624 us (seq=2135092223, len=7)  (+43 us)

  also regression tested existing SO_TIMESTAMP(NS|ING) interfaces
 
Comments:

# overloading SCM_TIMESTAMPING

This patchset reuses SCM_TIMESTAMPING to return new kinds of
timestamps. It is possible to create a new SCM_.. and struct,
but both socket option and flags-based interface can in principle
be equivalent feature-wise. In that case, it is preferable if
they return information in the same format.

# SO_TIMESTAMPING / MSG_TSTAMP feature parity

This patchset does not implement a fully equivalent feature set yet.
Not included is a draft patch that adds the functionality of
MSG_TSTAMP_ENQ and MSG_TSTAMP_ACK to SO_TIMESTAMPING. It is trivial,
save from the fact that these new options overflow sk_flags. The
patch introduces a separate timestamping sk_tsflags.

[PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Willem de Bruijn]

Applications that request kernel transmit timestamps with
SO_TIMESTAMPING read timestamps using recvmsg() ancillary data.
This patch explicitly defines the struct that applications read, and
the semantics of its fields.

The code is backward compatible with legacy applications that treat
the ancillary data as an anonymous array 'struct timespec data[3]'.

Beyond documenting existing use, it adds support for new timestamping
points in the kernel tx datapath. On tx, the scm_timestamping struct
is always accompanied with an error message of type sock_exterr_skb.

This patch defines the previously unused field ee_info in that struct
as an explicit type field, communicating the type of each timestamp
in the three struct timespec in scm_timestamping. This does not change
legacy expectations, but allows returning multiple timestamp types to
the calling process.

This patch does not modify the reception path. On rx, SO_TIMESTAMPING
csmgs are not accompanied by a struct similar to sock_exterr_skb. If
at some point rx timestamp points are added, a similar extension in a
new cmsg can be defined.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/linux/skbuff.h        |  2 ++
 include/uapi/linux/errqueue.h | 19 +++++++++++++++++++
 net/core/skbuff.c             |  1 +
 net/socket.c                  | 33 +++++++++++++++++++--------------
 4 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index ec89301..c74aab5 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -260,6 +260,8 @@ enum {
 	SKBTX_SHARED_FRAG = 1 << 5,
 };
 
+#define SKBTX_ANY_TSTAMP	(SKBTX_HW_TSTAMP | SKBTX_SW_TSTAMP)
+
 /*
  * The callback notifies userspace to release buffers when skb DMA is done in
  * lower device, the skb last reference should be 0 when calling this.
diff --git a/include/uapi/linux/errqueue.h b/include/uapi/linux/errqueue.h
index aacd4fb..5d93d0b 100644
--- a/include/uapi/linux/errqueue.h
+++ b/include/uapi/linux/errqueue.h
@@ -22,5 +22,24 @@ struct sock_extended_err {
 
 #define SO_EE_OFFENDER(ee)	((struct sockaddr*)((ee)+1))
 
+/**
+ *	struct scm_timestamping - timestamps exposed through cmsg
+ *
+ *	The timestamping interfaces SO_TIMESTAMPING, MSG_TSTAMP_*
+ *	communicate network timestamps by passing this struct in a cmsg with
+ *	recvmsg(). See Documentation/networking/timestamping.txt for details.
+ */
+struct scm_timestamping {
+	struct timespec ts[3];
+};
+
+#define SCM_TSTAMP_SND		0x1	/* driver passed skb to NIC */
+#define SCM_TSTAMP_ACK		0x2	/* transport layer saw ACK */
+#define SCM_TSTAMP_ENQ		0x4	/* stack passed skb to TC layer */
+#define SCM_TSTAMP_RCV		0x8	/* stack received skb */
+#define SCM_TSTAMP_HWSYS	0x10	/* NIC tstamp in system format */
+#define SCM_TSTAMP_HWRAW	0x20	/* NIC tstamp in native format */
+
+#define SCM_TSTAMP_OFF(n, ts)	(ts << (10 * n))
 
 #endif /* _UAPI_LINUX_ERRQUEUE_H */
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index c1a3303..1bcd05d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3521,6 +3521,7 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 	memset(serr, 0, sizeof(*serr));
 	serr->ee.ee_errno = ENOMSG;
 	serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
+	serr->ee.ee_info = hwtstamps ? 0 : SCM_TSTAMP_SND;
 
 	err = sock_queue_err_skb(sk, skb);
 
diff --git a/net/socket.c b/net/socket.c
index abf56b2..a31138d 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -106,6 +106,7 @@
 #include <linux/sockios.h>
 #include <linux/atalk.h>
 #include <net/busy_poll.h>
+#include <linux/errqueue.h>
 
 #ifdef CONFIG_NET_RX_BUSY_POLL
 unsigned int sysctl_net_busy_read __read_mostly;
@@ -696,9 +697,10 @@ EXPORT_SYMBOL(kernel_sendmsg);
 void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 	struct sk_buff *skb)
 {
+	struct sock_exterr_skb *serr = SKB_EXT_ERR(skb);
 	int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
-	struct timespec ts[3];
-	int empty = 1;
+	struct scm_timestamping tss;
+	int tstype = 0, is_tx = skb_shinfo(skb)->tx_flags & SKBTX_ANY_TSTAMP;
 	struct skb_shared_hwtstamps *shhwtstamps =
 		skb_hwtstamps(skb);
 
@@ -714,28 +716,31 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 			put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMP,
 				 sizeof(tv), &tv);
 		} else {
-			skb_get_timestampns(skb, &ts[0]);
+			struct timespec ts;
+			skb_get_timestampns(skb, &ts);
 			put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPNS,
-				 sizeof(ts[0]), &ts[0]);
+				 sizeof(ts), &ts);
 		}
 	}
 
-
-	memset(ts, 0, sizeof(ts));
+	memset(&tss, 0, sizeof(tss));
 	if (sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) &&
-	    ktime_to_timespec_cond(skb->tstamp, ts + 0))
-		empty = 0;
+	    ktime_to_timespec_cond(skb->tstamp, tss.ts + 0))
+		tstype |= is_tx ? serr->ee.ee_info : SCM_TSTAMP_RCV;
 	if (shhwtstamps) {
 		if (sock_flag(sk, SOCK_TIMESTAMPING_SYS_HARDWARE) &&
-		    ktime_to_timespec_cond(shhwtstamps->syststamp, ts + 1))
-			empty = 0;
+		    ktime_to_timespec_cond(shhwtstamps->syststamp, tss.ts + 1))
+			tstype |= SCM_TSTAMP_OFF(1, SCM_TSTAMP_HWSYS);
 		if (sock_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE) &&
-		    ktime_to_timespec_cond(shhwtstamps->hwtstamp, ts + 2))
-			empty = 0;
+		    ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2))
+			tstype |= SCM_TSTAMP_OFF(2, SCM_TSTAMP_HWRAW);
 	}
-	if (!empty)
+	if (tstype) {
+		if (is_tx)
+			serr->ee.ee_info = tstype;
 		put_cmsg(msg, SOL_SOCKET,
-			 SCM_TIMESTAMPING, sizeof(ts), &ts);
+			 SCM_TIMESTAMPING, sizeof(tss), &tss);
+	}
 }
 EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
 
-- 
2.0.0.526.g5318336

[PATCH net-next v2 2/8] net-timestamp: MSG_TSTAMP one-shot tx timestamps

[Willem de Bruijn]

The kernel support datagram tx timestamping through socket option
SO_TIMESTAMPING. This patch add send() flag MSG_TSTAMP to allow
selectively requesting a timestamp for a single packet.

MSG_TSTAMP does not depend on SO_TIMESTAMPING. Enabling both
concurrently is redundant, but safe.

This patch adds support for IPv4 and IPv6 UDP sendmsg().

The feature maintains semantics of the socket option: with IP
fragmentation, only the first fragment is timestamped. This
should not happen, but can be forced, e.g., by disabling PMTU
on UDP.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/linux/skbuff.h | 10 ++++++++++
 include/linux/socket.h |  1 +
 include/net/sock.h     |  5 +++--
 net/ipv4/udp.c         |  1 +
 net/ipv6/ip6_output.c  |  4 +++-
 net/socket.c           |  3 ++-
 6 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c74aab5..977596d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2738,6 +2738,16 @@ static inline void skb_tx_timestamp(struct sk_buff *skb)
 	sw_tx_timestamp(skb);
 }
 
+static inline u8 skbflags_tx_tstamp(int flags)
+{
+	u8 tx_flags = 0;
+
+	if (unlikely(flags & MSG_TSTAMP))
+		tx_flags |= SKBTX_SW_TSTAMP;
+
+	return tx_flags;
+}
+
 /**
  * skb_complete_wifi_ack - deliver skb with wifi status
  *
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 8e98297..ce4101e 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -253,6 +253,7 @@ struct ucred {
 #define MSG_MORE	0x8000	/* Sender will send more */
 #define MSG_WAITFORONE	0x10000	/* recvmmsg(): block until 1+ packets avail */
 #define MSG_SENDPAGE_NOTLAST 0x20000 /* sendpage() internal : not the last page */
+#define MSG_TSTAMP	0x100000
 #define MSG_EOF         MSG_FIN
 
 #define MSG_FASTOPEN	0x20000000	/* Send data in TCP SYN */
diff --git a/include/net/sock.h b/include/net/sock.h
index 8d4c947..62bcaa9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2140,14 +2140,15 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
 	 * - receive time stamping in software requested (SOCK_RCVTSTAMP
 	 *   or SOCK_TIMESTAMPING_RX_SOFTWARE)
 	 * - software time stamp available and wanted
-	 *   (SOCK_TIMESTAMPING_SOFTWARE)
+	 *   (SOCK_TIMESTAMPING_SOFTWARE || SKBTX_SW_TSTAMP)
 	 * - hardware time stamps available and wanted
 	 *   (SOCK_TIMESTAMPING_SYS_HARDWARE or
 	 *   SOCK_TIMESTAMPING_RAW_HARDWARE)
 	 */
 	if (sock_flag(sk, SOCK_RCVTSTAMP) ||
 	    sock_flag(sk, SOCK_TIMESTAMPING_RX_SOFTWARE) ||
-	    (kt.tv64 && sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE)) ||
+	    (kt.tv64 && (sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) ||
+	     skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)) ||
 	    (hwtstamps->hwtstamp.tv64 &&
 	     sock_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE)) ||
 	    (hwtstamps->syststamp.tv64 &&
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index d92f94b..9127aab 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -967,6 +967,7 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 	ipc.oif = sk->sk_bound_dev_if;
 
 	sock_tx_timestamp(sk, &ipc.tx_flags);
+	ipc.tx_flags |= skbflags_tx_tstamp(msg->msg_flags);
 
 	if (msg->msg_controllen) {
 		err = ip_cmsg_send(sock_net(sk), msg, &ipc,
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index cb9df0e..7306c5d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1270,8 +1270,10 @@ emsgsize:
 	}
 
 	/* For UDP, check if TX timestamp is enabled */
-	if (sk->sk_type == SOCK_DGRAM)
+	if (sk->sk_type == SOCK_DGRAM) {
 		sock_tx_timestamp(sk, &tx_flags);
+		tx_flags |= skbflags_tx_tstamp(flags);
+	}
 
 	/*
 	 * Let's try using as much space as possible.
diff --git a/net/socket.c b/net/socket.c
index a31138d..9f69a25 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -724,7 +724,8 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 	}
 
 	memset(&tss, 0, sizeof(tss));
-	if (sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) &&
+	if ((sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) ||
+	     skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP) &&
 	    ktime_to_timespec_cond(skb->tstamp, tss.ts + 0))
 		tstype |= is_tx ? serr->ee.ee_info : SCM_TSTAMP_RCV;
 	if (shhwtstamps) {
-- 
2.0.0.526.g5318336

[PATCH net-next v2 3/8] net-timestamp: tx timestamp without payload

[Willem de Bruijn]

Applications receive tx timestamps from the kernel by reading the
original packet from the socket error queue with sendmsg() and
processing an ancillary data item that holds the timestamps.

If the application is only interested in the timestamp, then looping
the whole packet back up to userspace wastes socket buffer space
(SO_RCVBUF). This is especially important when the same packet is
enqueued repeatedly with multiple timestamps.

This patch adds a socket option to loop the timestamp on top of an
empty packet instead of a clone of the original.

The option is only implemented for tx timestamps. Code that dequeues
from an sk_error_queue onto which skb_tstamp_tx enqueues has to be
able to handle zero-length packets.  Common implementations peek into
the packet headers, for instance to learn the address for msg_namelen.
When the queued skb has no payload, this data is unavailable and thus
not returned. skb_dequeue(sk->sk_error_queue) callers have been
audited to avoid accessing packet contents and fixed where needed
(IP, IPv6, RxRPC).

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/net/sock.h              |  1 +
 include/uapi/linux/net_tstamp.h |  7 ++++---
 net/core/skbuff.c               | 16 ++++++++++++----
 net/core/sock.c                 |  4 ++++
 net/ipv4/ip_sockglue.c          |  4 ++--
 net/ipv6/datagram.c             |  4 ++--
 net/rxrpc/ar-error.c            |  5 +++++
 7 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 62bcaa9..7a97200 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -692,6 +692,7 @@ enum sock_flags {
 	SOCK_TIMESTAMPING_SOFTWARE,     /* %SOF_TIMESTAMPING_SOFTWARE */
 	SOCK_TIMESTAMPING_RAW_HARDWARE, /* %SOF_TIMESTAMPING_RAW_HARDWARE */
 	SOCK_TIMESTAMPING_SYS_HARDWARE, /* %SOF_TIMESTAMPING_SYS_HARDWARE */
+	SOCK_TIMESTAMPING_OPT_TSONLY,	/* %SOF_TIMESTAMPING_OPT_TSONLY */
 	SOCK_FASYNC, /* fasync() active */
 	SOCK_RXQ_OVFL,
 	SOCK_ZEROCOPY, /* buffers from userspace */
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index f53879c..438068a 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -20,9 +20,10 @@ enum {
 	SOF_TIMESTAMPING_SOFTWARE = (1<<4),
 	SOF_TIMESTAMPING_SYS_HARDWARE = (1<<5),
 	SOF_TIMESTAMPING_RAW_HARDWARE = (1<<6),
-	SOF_TIMESTAMPING_MASK =
-	(SOF_TIMESTAMPING_RAW_HARDWARE - 1) |
-	SOF_TIMESTAMPING_RAW_HARDWARE
+	SOF_TIMESTAMPING_OPT_TSONLY = (1<<7),
+
+	SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_OPT_TSONLY - 1) |
+				 SOF_TIMESTAMPING_OPT_TSONLY
 };
 
 /**
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 1bcd05d..1091a74 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3501,6 +3501,13 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 	if (!sk)
 		return;
 
+	if (sock_flag(sk, SOCK_TIMESTAMPING_OPT_TSONLY))
+		skb = alloc_skb(0, GFP_ATOMIC);
+	else
+		skb = skb_clone(orig_skb, GFP_ATOMIC);
+	if (!skb)
+		return;
+
 	if (hwtstamps) {
 		*skb_hwtstamps(orig_skb) =
 			*hwtstamps;
@@ -3510,12 +3517,13 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 		 * so keep the shared tx_flags and only
 		 * store software time stamp
 		 */
-		orig_skb->tstamp = ktime_get_real();
+		skb->tstamp = ktime_get_real();
 	}
 
-	skb = skb_clone(orig_skb, GFP_ATOMIC);
-	if (!skb)
-		return;
+	if (!skb->len) {
+		skb_shinfo(skb)->tx_flags = skb_shinfo(orig_skb)->tx_flags;
+		*skb_hwtstamps(skb) = *skb_hwtstamps(orig_skb);
+	}
 
 	serr = SKB_EXT_ERR(skb);
 	memset(serr, 0, sizeof(*serr));
diff --git a/net/core/sock.c b/net/core/sock.c
index 026e01f..708c89f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -866,6 +866,8 @@ set_rcvbuf:
 				  val & SOF_TIMESTAMPING_SYS_HARDWARE);
 		sock_valbool_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE,
 				  val & SOF_TIMESTAMPING_RAW_HARDWARE);
+		sock_valbool_flag(sk, SOCK_TIMESTAMPING_OPT_TSONLY,
+				  val & SOF_TIMESTAMPING_OPT_TSONLY);
 		break;
 
 	case SO_RCVLOWAT:
@@ -1106,6 +1108,8 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
 			v.val |= SOF_TIMESTAMPING_SYS_HARDWARE;
 		if (sock_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE))
 			v.val |= SOF_TIMESTAMPING_RAW_HARDWARE;
+		if (sock_flag(sk, SOCK_TIMESTAMPING_OPT_TSONLY))
+			v.val |= SOF_TIMESTAMPING_OPT_TSONLY;
 		break;
 
 	case SO_RCVTIMEO:
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 64741b9..f17f34f 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -432,7 +432,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
 
 	serr = SKB_EXT_ERR(skb);
 
-	if (sin) {
+	if (sin && skb->len) {
 		sin->sin_family = AF_INET;
 		sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
 						   serr->addr_offset);
@@ -444,7 +444,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
 	memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
 	sin = &errhdr.offender;
 	sin->sin_family = AF_UNSPEC;
-	if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP) {
+	if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP && skb->len) {
 		struct inet_sock *inet = inet_sk(sk);
 
 		sin->sin_family = AF_INET;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index c3bf2d2..391e6e0 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -358,7 +358,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
 
 	serr = SKB_EXT_ERR(skb);
 
-	if (sin) {
+	if (sin && skb->len) {
 		const unsigned char *nh = skb_network_header(skb);
 		sin->sin6_family = AF_INET6;
 		sin->sin6_flowinfo = 0;
@@ -383,7 +383,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
 	memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
 	sin = &errhdr.offender;
 	sin->sin6_family = AF_UNSPEC;
-	if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
+	if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL && skb->len) {
 		sin->sin6_family = AF_INET6;
 		sin->sin6_flowinfo = 0;
 		sin->sin6_port = 0;
diff --git a/net/rxrpc/ar-error.c b/net/rxrpc/ar-error.c
index db57458..f9a65c0 100644
--- a/net/rxrpc/ar-error.c
+++ b/net/rxrpc/ar-error.c
@@ -42,6 +42,11 @@ void rxrpc_UDP_error_report(struct sock *sk)
 		_leave("UDP socket errqueue empty");
 		return;
 	}
+	if (!skb->len) {
+		_leave("UDP empty message");
+		kfree_skb(skb);
+		return;
+	}
 
 	rxrpc_new_skb(skb);
 
-- 
2.0.0.526.g5318336

[PATCH net-next v2 4/8] net-timestamp: TCP timestamping

[Willem de Bruijn]

TCP timestamping extends datagram MSG_TSTAMP support to bytestreams.

Bytestreams do not have a 1:1 relationship between send() buffers and
network packets. The feature interprets a send call with MSG_TSTAMP on
a bytestream as a request for a timestamp for the last byte in the
buffer.

The choice corresponds to a request for a timestamp when all bytes in
the buffer have been sent. That assumption depends on in-order kernel
transmission. This is the common case. That said, it is possible to
construct a traffic shaping tree that would result in reordering.
The guarantee is strong, then, but not ironclad.

This implementation supports send and sendpages (splice). GSO replaces
one large packet with multiple smaller packets. This patch also copies
the option into the correct smaller packet.

This patch does not yet support timestamping on data in an initial TCP
Fast Open SYN, because that takes a very different data path.

The implementation supports a single timestamp per packet. To avoid
having multiple timestamp requests per sk_buff, the skb is locked
against extension once the flag is set.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 net/core/skbuff.c      | 12 ++++++++++++
 net/ipv4/tcp.c         | 21 +++++++++++++++++----
 net/ipv4/tcp_offload.c |  4 ++++
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 1091a74..7657658 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -69,6 +69,7 @@
 #include <net/checksum.h>
 #include <net/ip6_checksum.h>
 #include <net/xfrm.h>
+#include <net/tcp.h>
 
 #include <asm/uaccess.h>
 #include <trace/events/skb.h>
@@ -3496,6 +3497,7 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 	struct sock *sk = orig_skb->sk;
 	struct sock_exterr_skb *serr;
 	struct sk_buff *skb;
+	__u32 key = 0;
 	int err;
 
 	if (!sk)
@@ -3525,11 +3527,21 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 		*skb_hwtstamps(skb) = *skb_hwtstamps(orig_skb);
 	}
 
+	if (orig_skb->sk && orig_skb->sk->sk_protocol == IPPROTO_TCP) {
+		if (orig_skb->fclone == SKB_FCLONE_CLONE)
+			key = TCP_SKB_CB(orig_skb - 1)->end_seq;
+		else /* after GSO segmentation, fclone no longer works */
+			key = ntohl(tcp_hdr(skb)->seq) +
+			      ntohs(ip_hdr(skb)->tot_len) -
+			      ip_hdrlen(skb) - tcp_hdrlen(skb);
+	}
+
 	serr = SKB_EXT_ERR(skb);
 	memset(serr, 0, sizeof(*serr));
 	serr->ee.ee_errno = ENOMSG;
 	serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
 	serr->ee.ee_info = hwtstamps ? 0 : SCM_TSTAMP_SND;
+	serr->ee.ee_data = key;
 
 	err = sock_queue_err_skb(sk, skb);
 
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index eb1dde3..4ceecd9 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -878,6 +878,11 @@ static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
 	return mss_now;
 }
 
+static bool tcp_skb_can_extend(struct sk_buff *skb)
+{
+	return !(skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP);
+}
+
 static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
 				size_t size, int flags)
 {
@@ -911,7 +916,8 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
 		int copy, i;
 		bool can_coalesce;
 
-		if (!tcp_send_head(sk) || (copy = size_goal - skb->len) <= 0) {
+		if (!tcp_send_head(sk) || (copy = size_goal - skb->len) <= 0 ||
+		    !tcp_skb_can_extend(skb)) {
 new_segment:
 			if (!sk_stream_memory_free(sk))
 				goto wait_for_sndbuf;
@@ -959,8 +965,10 @@ new_segment:
 
 		copied += copy;
 		offset += copy;
-		if (!(size -= copy))
+		if (!(size -= copy)) {
+			skb_shinfo(skb)->tx_flags |= skbflags_tx_tstamp(flags);
 			goto out;
+		}
 
 		if (skb->len < size_goal || (flags & MSG_OOB))
 			continue;
@@ -1160,7 +1168,7 @@ int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 				copy = max - skb->len;
 			}
 
-			if (copy <= 0) {
+			if (copy <= 0 || !tcp_skb_can_extend(skb)) {
 new_segment:
 				/* Allocate new segment. If the interface is SG,
 				 * allocate skb fitting to single page.
@@ -1252,8 +1260,10 @@ new_segment:
 
 			from += copy;
 			copied += copy;
-			if ((seglen -= copy) == 0 && iovlen == 0)
+			if ((seglen -= copy) == 0 && iovlen == 0) {
+				skb_shinfo(skb)->tx_flags |= skbflags_tx_tstamp(flags);
 				goto out;
+			}
 
 			if (skb->len < max || (flags & MSG_OOB) || unlikely(tp->repair))
 				continue;
@@ -1616,6 +1626,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 	struct sk_buff *skb;
 	u32 urg_hole = 0;
 
+	if (unlikely(flags & MSG_ERRQUEUE))
+		return ip_recv_error(sk, msg, len, addr_len);
+
 	if (sk_can_busy_loop(sk) && skb_queue_empty(&sk->sk_receive_queue) &&
 	    (sk->sk_state == TCP_ESTABLISHED))
 		sk_busy_loop(sk, nonblock);
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index 4e86c59..730c2f6 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -134,6 +134,10 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
 				(__force u32)delta));
 	if (skb->ip_summed != CHECKSUM_PARTIAL)
 		th->check = gso_make_checksum(skb, ~th->check);
+
+	if (unlikely(skb_shinfo(gso_skb)->tx_flags & SKBTX_SW_TSTAMP))
+		skb_shinfo(skb)->tx_flags |= SKBTX_SW_TSTAMP;
+
 out:
 	return segs;
 }
-- 
2.0.0.526.g5318336

[PATCH net-next v2 5/8] net-timestamp: ACK timestamp for bytestreams

[Willem de Bruijn]

This patch adds send() flag MSG_TSTAMP_ACK, a request for a timestamp
when the last byte in the send buffer is acknowledged. It implements
the feature for TCP.

The timestamp is generated when the TCP socket cumulative ACK is
moved beyond the tracked seqno for the first time. This corresponds
to the other peer having received all data up until this byte. The
feature ignores SACK and FACK, because those acknowledge the
specific byte, but not necessarily the entire contents of the buffer
passed in send()

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/linux/skbuff.h | 17 ++++++++++++++---
 include/linux/socket.h |  2 ++
 include/net/sock.h     |  4 ++--
 net/core/skbuff.c      | 18 ++++++++++++++----
 net/ipv4/tcp.c         |  2 +-
 net/ipv4/tcp_input.c   |  4 ++++
 net/socket.c           |  2 +-
 7 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 977596d..0205184 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -258,9 +258,12 @@ enum {
 	 * all frags to avoid possible bad checksum
 	 */
 	SKBTX_SHARED_FRAG = 1 << 5,
+
+	SKBTX_ACK_TSTAMP = 1 << 6,
 };
 
-#define SKBTX_ANY_TSTAMP	(SKBTX_HW_TSTAMP | SKBTX_SW_TSTAMP)
+#define SKBTX_ANY_SW_TSTAMP 	(SKBTX_SW_TSTAMP | SKBTX_ACK_TSTAMP)
+#define SKBTX_ANY_TSTAMP	(SKBTX_HW_TSTAMP | SKBTX_ANY_SW_TSTAMP)
 
 /*
  * The callback notifies userspace to release buffers when skb DMA is done in
@@ -2699,6 +2702,10 @@ static inline bool skb_defer_rx_timestamp(struct sk_buff *skb)
 void skb_complete_tx_timestamp(struct sk_buff *skb,
 			       struct skb_shared_hwtstamps *hwtstamps);
 
+void __skb_tstamp_tx(struct sk_buff *orig_skb,
+		     struct skb_shared_hwtstamps *hwtstamps,
+		     struct sock *sk, int tstype);
+
 /**
  * skb_tstamp_tx - queue clone of skb with send time stamps
  * @orig_skb:	the original outgoing packet
@@ -2742,8 +2749,12 @@ static inline u8 skbflags_tx_tstamp(int flags)
 {
 	u8 tx_flags = 0;
 
-	if (unlikely(flags & MSG_TSTAMP))
-		tx_flags |= SKBTX_SW_TSTAMP;
+	if (unlikely(flags & MSG_TSTAMP_MASK)) {
+		if (flags & MSG_TSTAMP)
+			tx_flags |= SKBTX_SW_TSTAMP;
+		if (flags & MSG_TSTAMP_ACK)
+			tx_flags |= SKBTX_ACK_TSTAMP;
+	}
 
 	return tx_flags;
 }
diff --git a/include/linux/socket.h b/include/linux/socket.h
index ce4101e..68d5f48 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -254,6 +254,8 @@ struct ucred {
 #define MSG_WAITFORONE	0x10000	/* recvmmsg(): block until 1+ packets avail */
 #define MSG_SENDPAGE_NOTLAST 0x20000 /* sendpage() internal : not the last page */
 #define MSG_TSTAMP	0x100000
+#define MSG_TSTAMP_ACK	0x200000
+#define MSG_TSTAMP_MASK	(MSG_TSTAMP | MSG_TSTAMP_ACK)
 #define MSG_EOF         MSG_FIN
 
 #define MSG_FASTOPEN	0x20000000	/* Send data in TCP SYN */
diff --git a/include/net/sock.h b/include/net/sock.h
index 7a97200..489143b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2141,7 +2141,7 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
 	 * - receive time stamping in software requested (SOCK_RCVTSTAMP
 	 *   or SOCK_TIMESTAMPING_RX_SOFTWARE)
 	 * - software time stamp available and wanted
-	 *   (SOCK_TIMESTAMPING_SOFTWARE || SKBTX_SW_TSTAMP)
+	 *   (SOCK_TIMESTAMPING_SOFTWARE || SKBTX_ANY_SW_TSTAMP)
 	 * - hardware time stamps available and wanted
 	 *   (SOCK_TIMESTAMPING_SYS_HARDWARE or
 	 *   SOCK_TIMESTAMPING_RAW_HARDWARE)
@@ -2149,7 +2149,7 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
 	if (sock_flag(sk, SOCK_RCVTSTAMP) ||
 	    sock_flag(sk, SOCK_TIMESTAMPING_RX_SOFTWARE) ||
 	    (kt.tv64 && (sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) ||
-	     skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)) ||
+	     skb_shinfo(skb)->tx_flags & SKBTX_ANY_SW_TSTAMP)) ||
 	    (hwtstamps->hwtstamp.tv64 &&
 	     sock_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE)) ||
 	    (hwtstamps->syststamp.tv64 &&
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7657658..8c479df 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3491,10 +3491,10 @@ int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
 }
 EXPORT_SYMBOL(sock_queue_err_skb);
 
-void skb_tstamp_tx(struct sk_buff *orig_skb,
-		struct skb_shared_hwtstamps *hwtstamps)
+void __skb_tstamp_tx(struct sk_buff *orig_skb,
+		     struct skb_shared_hwtstamps *hwtstamps,
+		     struct sock *sk, int tstype)
 {
-	struct sock *sk = orig_skb->sk;
 	struct sock_exterr_skb *serr;
 	struct sk_buff *skb;
 	__u32 key = 0;
@@ -3534,13 +3534,15 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 			key = ntohl(tcp_hdr(skb)->seq) +
 			      ntohs(ip_hdr(skb)->tot_len) -
 			      ip_hdrlen(skb) - tcp_hdrlen(skb);
+	} else if (tstype == SCM_TSTAMP_ACK) {
+		key = TCP_SKB_CB(orig_skb)->end_seq;
 	}
 
 	serr = SKB_EXT_ERR(skb);
 	memset(serr, 0, sizeof(*serr));
 	serr->ee.ee_errno = ENOMSG;
 	serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
-	serr->ee.ee_info = hwtstamps ? 0 : SCM_TSTAMP_SND;
+	serr->ee.ee_info = tstype;
 	serr->ee.ee_data = key;
 
 	err = sock_queue_err_skb(sk, skb);
@@ -3548,6 +3550,14 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
 	if (err)
 		kfree_skb(skb);
 }
+EXPORT_SYMBOL_GPL(__skb_tstamp_tx);
+
+void skb_tstamp_tx(struct sk_buff *orig_skb,
+		   struct skb_shared_hwtstamps *hwtstamps)
+{
+	return __skb_tstamp_tx(orig_skb, hwtstamps, orig_skb->sk,
+			       hwtstamps ? 0 : SCM_TSTAMP_SND);
+}
 EXPORT_SYMBOL_GPL(skb_tstamp_tx);
 
 void skb_complete_wifi_ack(struct sk_buff *skb, bool acked)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 4ceecd9..b792642 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -880,7 +880,7 @@ static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
 
 static bool tcp_skb_can_extend(struct sk_buff *skb)
 {
-	return !(skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP);
+	return !(skb_shinfo(skb)->tx_flags & SKBTX_ANY_SW_TSTAMP);
 }
 
 static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index bb68496..cf3fb2c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -74,6 +74,7 @@
 #include <linux/ipsec.h>
 #include <asm/unaligned.h>
 #include <net/netdma.h>
+#include <linux/errqueue.h>
 
 int sysctl_tcp_timestamps __read_mostly = 1;
 int sysctl_tcp_window_scaling __read_mostly = 1;
@@ -3103,6 +3104,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
 		if (!fully_acked)
 			break;
 
+		if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_ACK_TSTAMP))
+			__skb_tstamp_tx(skb, NULL, sk, SCM_TSTAMP_ACK);
+
 		tcp_unlink_write_queue(skb, sk);
 		sk_wmem_free_skb(sk, skb);
 		if (skb == tp->retransmit_skb_hint)
diff --git a/net/socket.c b/net/socket.c
index 9f69a25..ea807c8 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -725,7 +725,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 
 	memset(&tss, 0, sizeof(tss));
 	if ((sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) ||
-	     skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP) &&
+	     skb_shinfo(skb)->tx_flags & SKBTX_ANY_SW_TSTAMP) &&
 	    ktime_to_timespec_cond(skb->tstamp, tss.ts + 0))
 		tstype |= is_tx ? serr->ee.ee_info : SCM_TSTAMP_RCV;
 	if (shhwtstamps) {
-- 
2.0.0.526.g5318336

[PATCH net-next v2 6/8] net-timestamp: ENQ timestamp on enqueue to traffic shaping layer

[Willem de Bruijn]

Kernel transmit latency is often incurred in the traffic shaping
layer. This patch adds a new timestamp on transmission just before
entering traffic shaping. When data travels through multiple devices
(bonding, tunneling, ...) each device will export an individual
timestamp.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/linux/skbuff.h | 8 +++++++-
 include/linux/socket.h | 3 ++-
 net/core/dev.c         | 4 ++++
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0205184..ec76556 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -260,9 +260,13 @@ enum {
 	SKBTX_SHARED_FRAG = 1 << 5,
 
 	SKBTX_ACK_TSTAMP = 1 << 6,
+
+	SKBTX_ENQ_TSTAMP = 1 << 7,
 };
 
-#define SKBTX_ANY_SW_TSTAMP 	(SKBTX_SW_TSTAMP | SKBTX_ACK_TSTAMP)
+#define SKBTX_ANY_SW_TSTAMP	(SKBTX_SW_TSTAMP  | \
+				 SKBTX_ACK_TSTAMP | \
+				 SKBTX_ENQ_TSTAMP)
 #define SKBTX_ANY_TSTAMP	(SKBTX_HW_TSTAMP | SKBTX_ANY_SW_TSTAMP)
 
 /*
@@ -2754,6 +2758,8 @@ static inline u8 skbflags_tx_tstamp(int flags)
 			tx_flags |= SKBTX_SW_TSTAMP;
 		if (flags & MSG_TSTAMP_ACK)
 			tx_flags |= SKBTX_ACK_TSTAMP;
+		if (flags & MSG_TSTAMP_ENQ)
+			tx_flags |= SKBTX_ENQ_TSTAMP;
 	}
 
 	return tx_flags;
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 68d5f48..6d21582 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -255,7 +255,8 @@ struct ucred {
 #define MSG_SENDPAGE_NOTLAST 0x20000 /* sendpage() internal : not the last page */
 #define MSG_TSTAMP	0x100000
 #define MSG_TSTAMP_ACK	0x200000
-#define MSG_TSTAMP_MASK	(MSG_TSTAMP | MSG_TSTAMP_ACK)
+#define MSG_TSTAMP_ENQ	0x400000
+#define MSG_TSTAMP_MASK	(MSG_TSTAMP | MSG_TSTAMP_ACK | MSG_TSTAMP_ENQ)
 #define MSG_EOF         MSG_FIN
 
 #define MSG_FASTOPEN	0x20000000	/* Send data in TCP SYN */
diff --git a/net/core/dev.c b/net/core/dev.c
index 6e2a2cd..b710213f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -132,6 +132,7 @@
 #include <linux/hashtable.h>
 #include <linux/vmalloc.h>
 #include <linux/if_macvlan.h>
+#include <linux/errqueue.h>
 
 #include "net-sysfs.h"
 
@@ -2859,6 +2860,9 @@ static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv)
 
 	skb_reset_mac_header(skb);
 
+	if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_ENQ_TSTAMP))
+		__skb_tstamp_tx(skb, NULL, skb->sk, SCM_TSTAMP_ENQ);
+
 	/* Disable soft irqs for various locks below. Also
 	 * stops preemption for RCU.
 	 */
-- 
2.0.0.526.g5318336

[PATCH net-next v2 7/8] net-timestamp: expand documentation

[Willem de Bruijn]

Expand Documentation/networking/timestamping.txt with interface
details of MSG_TSTAMP and bytestream timestamping. Also minor
cleanup of the other text.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 Documentation/networking/timestamping.txt | 263 ++++++++++++++++++++++++++----
 1 file changed, 228 insertions(+), 35 deletions(-)

diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index bc35541..c00500a 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -1,4 +1,7 @@
-The existing interfaces for getting network packages time stamped are:
+
+1. Control Interfaces
+
+The interfaces for getting network packages time stamped are:
 
 * SO_TIMESTAMP
   Generate time stamp for each incoming packet using the (not necessarily
@@ -13,21 +16,47 @@ The existing interfaces for getting network packages time stamped are:
   Only for multicasts: approximate send time stamp by receiving the looped
   packet and using its receive time stamp.
 
-The following interface complements the existing ones: receive time
-stamps can be generated and returned for arbitrary packets and much
-closer to the point where the packet is really sent. Time stamps can
-be generated in software (as before) or in hardware (if the hardware
-has such a feature).
+* SO_TIMESTAMPING
+  Request timestamps on reception, transmission or both. Request hardware,
+  software or both timestamps.
+
+* MSG_TSTAMP..
+  Like SO_TIMESTAMPING, but unlike that socket option, request a timestamp
+  for the payload of one specific send() call only. Currently supports
+  only timestamping on transmission.
+
+
+1.1 SO_TIMESTAMP:
+
+This socket option enables timestamping of datagrams on the network reception
+path. Because the destination socket, if any, is not known early in the
+network stack, the feature has to be enabled for all possibly matching packets
+(i.e., datagrams). The same is true for all subsequent reception timestamp
+options, too.
+
+For interface details, see `man 7 socket`.
 
-SO_TIMESTAMPING:
+
+1.2 SO_TIMESTAMPNS:
+
+This option is identical to SO_TIMESTAMP except for the returned data type.
+Its struct timespec allows for higher resolution (ns) timestamps than the
+timeval of SO_TIMESTAMP (ms).
+
+
+1.3 SO_TIMESTAMPING:
 
 Instructs the socket layer which kind of information should be collected
-and/or reported.  The parameter is an integer with some of the following
-bits set. Setting other bits is an error and doesn't change the current
-state.
+and/or reported. SO_TIMESTAMPING supports multiple types of timestamps. The
+socket option is a bitmap, not a boolean, as a result. In an expression
+
+  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, (void *) val, &val);
+
+The parameter val is an integer with some of the following bits set. Setting
+other bits returns EINVAL and does not change the current state.
 
 Four of the bits are requests to the stack to try to generate
-timestamps.  Any combination of them is valid.
+timestamps. Any combination of them is valid.
 
 SOF_TIMESTAMPING_TX_HARDWARE:  try to obtain send time stamps in hardware
 SOF_TIMESTAMPING_TX_SOFTWARE:  try to obtain send time stamps in software
@@ -43,6 +72,10 @@ SOF_TIMESTAMPING_SOFTWARE:     report systime if available
 SOF_TIMESTAMPING_SYS_HARDWARE: report hwtimetrans if available
 SOF_TIMESTAMPING_RAW_HARDWARE: report hwtimeraw if available
 
+The interface supports one option
+
+SOF_TIMESTAMPING_OPT_TSONLY:   report a tx tstamp without looping pkt payload
+
 It is worth noting that timestamps may be collected for reasons other
 than being requested by a particular socket with
 SOF_TIMESTAMPING_[TR]X_(HARD|SOFT)WARE.  For example, most drivers that
@@ -50,45 +83,174 @@ can generate hardware receive timestamps ignore
 SOF_TIMESTAMPING_RX_HARDWARE.  It is still a good idea to set that flag
 in case future drivers pay attention.
 
-If timestamps are reported, they will appear in a control message with
-cmsg_level==SOL_SOCKET, cmsg_type==SO_TIMESTAMPING, and a payload like
-this:
+
+1.4 MSG_TSTAMP:
+
+The socket options enable timestamps for all datagrams on a socket
+until the configuration is again updated. Timestamps are often of
+interest only selectively, for instance for sampled monitoring or
+to instrument outliers. In these cases, continuous monitoring imposes
+unnecessary cost.
+
+MSG_TSTAMP and the MSG_TSTAMP_* flags are passed immediately with
+a send() call and request a timestamp only for the data in that
+buffer. They do not change socket state, nor do they depend on any
+of the socket options. Both can be used independently. Enabling
+both concurrently is safe, but redundant.
+
+MSG_TSTAMP:
+  generates the same timestamp as
+  SOF_TIMESTAMPING_TX_SOFTWARE | SOF_TIMESTAMPING_SOFTWARE: a transmit
+  timestamp in the device driver prior to handing to the NIC. As such
+  support for this timestamp is device driver specific.
+
+MSG_TSTAMP_ENQ:
+  generates a timestamp in the traffic shaping layer, prior to queuing
+  a packet. Kernel transmit latency is, if long, often dominated by
+  queueing delay. The difference between MSG_TSTAMP_ENQ and MSG_TSTAMP
+  will expose this delay indepedently from protocol processing. On
+  machines with virtual devices where a transmitted packet travels
+  through multiple devices and, hence, multiple traffic shaping
+  layers, a timestamp is returned for each layer. This enables fine
+  grained measurement of queueing delay.
+
+MSG_TSTAMP_ACK:
+  generates a timestamp when all data in the send buffer has been
+  acknowledged. This only makes sense for reliable protocols. It is
+  currently only implemented for TCP. For that protocol, it may
+  over-report measurement, because it defines when all data up to
+  and including the buffer was acknowledged (a cumulative ACK). It
+  ignores SACK and FACK.
+
+
+1.4.1 Bytestream Timestamps
+
+Unlike the socket options, the MSG_TSTAMP_.. interface supports
+timestamping of data in a bytestream. Each request is interpreted
+as a request for when the entire content of the buffer has passed a
+defined timestamping point. That is, a MSG_TSTAMP request records
+when all bytes have reached the device driver, regardless of how
+many packets the data has been converted into.
+
+In general, bytestreams have no natural delimiters and therefore
+correlating a timestamp with data is non-trivial. A range of bytes
+may be split across packets, packets may be merged (possibly merging
+two halves of two previously split, otherwise independent, buffers).
+These segments may be reordered and can even coexist for reliable
+protocols that implement retransmissions.
+
+It is essential that all timestamps implement the same semantics,
+regardless of all possible transformations, as otherwise they are
+incomparable. Handling "rare" corner cases differently from the
+simple case (a 1:1 mapping from buffer to skb) is insufficient
+because performance debugging often needs to focus on such outliers.
+
+In practice, timestamps can be correlated with segments of a
+bytestream consistently, if both semantics of the timestamp and the
+timing of measurement are chosen correctly. This challenge is no
+different from deciding on a strategy for IP fragmentation. There, the
+definition is that only the first fragment is timestamped. For
+bytestreams, we chose that a timestamp is generated only when all
+bytes have passed a point. The MSG_TSTAMP_ACK as defined is easy to
+implement and reason about. An implementation that has to take into
+account SACK would be more complex due to possible transmission holes
+and out of order arrival.
+
+On the host, TCP can also break the simple 1:1 mapping from buffer to
+skb by
+- appending a buffer to an existing skb (e.g., Nagle, cork and autocork)
+- MSS-based segmentation
+- generic segmentation offload (GSO)
+
+The implementation avoids the first by effectively closing an skb
+for appends once a timestamp flag is set. The stack avoids
+segmentation due to MSS. GSO is supported by copying the relevant
+flag from the original large packet into the last of the segmented
+MTU or smaller sized packets.
+
+This ensures that the timestamp is generated only when all bytes have
+passed a timestamp point, if the network stack does not reorder the
+packets. The stack indeed tries to avoid reordering. The one exception
+is under administrator control: it is possible to construct a traffic
+shaping setup that delays segments differently. Such a setup would be
+unusual.
+
+
+2 Data Interfaces
+
+The socket manual page describes how data is read from SO_TIMESTAMP
+and SO_TIMESTAMPNS. The other two interfaces use the same mechanism
+to return timestamps to the process.
+
+2.1 Reading TIMESTAMPING and MSG_TSTAMP records
+
+Timestamps can be read using the ancillary data feature of recvmsg().
+See `man 3 cmsg` for details of this interface. Timestamps are
+returned in a control message with cmsg_level SOL_SOCKET, cmsg_type
+SO_TIMESTAMPING, and payload of type
 
 struct scm_timestamping {
-	struct timespec systime;
-	struct timespec hwtimetrans;
-	struct timespec hwtimeraw;
+	struct timespec ts[3];
+};
+
+2.1.1 Transmit timestamps with MSG_ERRQUEUE
+
+For transmit timestamps the outgoing packet is looped back to
+the socket's error queue with the send time stamp(s) attached. A
+process receives the timestamps by calling recvmsg() with flag
+MSG_ERRQUEUE set and with a msg_control buffer sufficiently large
+to receive the relevant metadata structures. The recvmsg call returns
+the original outgoing data packet with two ancillary messages attached.
+A message of cm_level SOL_IP(V6) and cm_type IP(V6)_RECVERR embeds a
+struct sock_extended_err. This defines the error type. For timestamps,
+the ee_errno field is ENOMSG. The other ancillary message will have
+cm_level SOL_SOCKET and cm_type SCM_TIMESTAMPING. This embeds the
+struct scm_timestamping. Reading from the error queue is always a
+non-blocking operation. If the process wants to block for timestamps,
+it can use poll or select. In that case, the socket is ready for
+reading on POLLIN (not POLLERR).
+
+The semantics of the three struct timespec are defined by field
+ee_info in the extended error structure. It contains zero or one
+value SCM_TSTAMP_* for each struct timespec in scm_timestamping.
+In essence, it describes a
+
+struct scm_timestamping_types {
+	u32 tstype_field0:10;
+	u32 tstype_field1:10;
+	u32 tstype_field2:10;
+	u32 reserved:2;
 };
 
-recvmsg() can be used to get this control message for regular incoming
-packets. For send time stamps the outgoing packet is looped back to
-the socket's error queue with the send time stamp(s) attached. It can
-be received with recvmsg(flags=MSG_ERRQUEUE). The call returns the
-original outgoing packet data including all headers preprended down to
-and including the link layer, the scm_timestamping control message and
-a sock_extended_err control message with ee_errno==ENOMSG and
-ee_origin==SO_EE_ORIGIN_TIMESTAMPING. A socket with such a pending
-bounced packet is ready for reading as far as select() is concerned.
-If the outgoing packet has to be fragmented, then only the first
-fragment is time stamped and returned to the sending socket.
-
-All three values correspond to the same event in time, but were
+All three timestamps correspond to the same packet, but were
 generated in different ways. Each of these values may be empty (= all
 zero), in which case no such value was available. If the application
 is not interested in some of these values, they can be left blank to
 avoid the potential overhead of calculating them.
 
-systime is the value of the system time at that moment. This
+The SCM_TSTAMP_* types are closely related to the SOF_TIMESTAMPING_*
+and MSG_TSTAMP_* control fields discussed previously. They are defined
+as follows:
+
+SCM_TSTAMP_RCV records the system time in the rx softint path. This
 corresponds to the value also returned via SO_TIMESTAMP[NS]. If the
 time stamp was generated by hardware, then this field is
 empty. Otherwise it is filled in if SOF_TIMESTAMPING_SOFTWARE is
 set.
 
-hwtimeraw is the original hardware time stamp. Filled in if
+SCM_TSTAMP_SND records the system time in the transmit path as late
+as possible prior to handing the packet to the NIC. This is in the
+device driver path, so support is device dependent. See also the
+control option MSG_TSTAMP.
+
+Analogously, SCM_TSTAMP_ENQ and SCM_TSTAMP_ACK return timestamps
+generated by requests for MSG_TSTAMP_ENQ and MSG_TSTAMP_ACK.
+
+SCM_TSTAMP_HWSYS is the original hardware time stamp. Filled in if
 SOF_TIMESTAMPING_RAW_HARDWARE is set. No assumptions about its
 relation to system time should be made.
 
-hwtimetrans is the hardware time stamp transformed so that it
+SCM_TSTAMP_HWRAW is the hardware time stamp transformed so that it
 corresponds as good as possible to system time. This correlation is
 not perfect; as a consequence, sorting packets received via different
 NICs by their hwtimetrans may differ from the order in which they were
@@ -96,8 +258,39 @@ received. hwtimetrans may be non-monotonic even for the same NIC.
 Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support
 by the network device and will be empty without that support.
 
+2.1.1.1 Fragmentation
+
+Fragmentation of outgoing datagrams is rare, but is possible, e.g., by
+explicitly disabling PMTU discovery. If an outgoing packet is fragmented,
+then only the first fragment is timestamped and returned to the sending
+socket.
+
+2.1.1.2 Reading Payload
+
+The calling application is often not interested in receiving the whole
+packet payload that it passed to the stack originally: the socket
+error queue mechanism is just a method to piggyback the timestamp on.
+In this case, the application can choose to read datagrams with a
+smaller buffer, possibly even of length 0. The payload is truncated
+accordingly.
+
+Until the process calls recvmsg() on the error queue, however, the
+full packet is queued, taking up budget from SO_SNDBUF. By setting
+socket option SOF_TIMESTAMPING_OPT_TSONLY, the timestamp is looped
+back not onto the original packet, but an empty packet generated
+at recvmsg() time.
+
+2.1.2 Receive timestamps
+
+On reception, there is no reason to read from the socket error queue.
+The SCM_TIMESTAMPING ancillary data is sent along with the packet data
+on a normal recvmsg(). Since this is not a socket error, it is not
+accompanied by a message SOL_IP(V6)/IP(V6)_RECVERROR. In this case,
+the meaning of the three fields is implicitly defined. Field 0 holds
+a value of SCM_TSTAMP_RCV, 1 of type SCM_TSTAMP_HWSYS and 2 of type
+SCM_TSTAMP_HWRAW.
 
-SIOCSHWTSTAMP, SIOCGHWTSTAMP:
+3. Hardware Timestamping configuration: SIOCSHWTSTAMP and SIOCGHWTSTAMP
 
 Hardware time stamping must also be initialized for each device driver
 that is expected to do hardware time stamping. The parameter is defined in
@@ -169,7 +362,7 @@ enum {
 };
 
 
-DEVICE IMPLEMENTATION
+Hardware Timestamping Implementation: Device Drivers
 
 A driver which supports hardware time stamping must support the
 SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
-- 
2.0.0.526.g5318336

[PATCH net-next v2 8/8] net-timestamp: SOCK_RAW and PING timestamping

[Willem de Bruijn]

Add SO_TIMESTAMPING to sockets of type PF_INET[6]/SOCK_RAW.
Add MSG_TSTAMP support to these sockets and ping sockets.
Ping sockets already supported SO_TIMESTAMPING, though the
feature was broken.

SOCK_RAW support was tested:
- socket option and flag
- with and without IP_HDRINCL

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=77221

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 net/ipv4/ip_output.c | 7 +++----
 net/ipv4/ping.c      | 1 +
 net/ipv4/raw.c       | 6 ++++++
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 8d3b6b0..234a7ea 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -962,10 +962,6 @@ alloc_new_skb:
 							   sk->sk_allocation);
 				if (unlikely(skb == NULL))
 					err = -ENOBUFS;
-				else
-					/* only the initial fragment is
-					   time stamped */
-					cork->tx_flags = 0;
 			}
 			if (skb == NULL)
 				goto error;
@@ -1010,6 +1006,9 @@ alloc_new_skb:
 			exthdrlen = 0;
 			csummode = CHECKSUM_NONE;
 
+			/* only the initial fragment is time stamped */
+			cork->tx_flags = 0;
+
 			/*
 			 * Put the packet on the pending queue.
 			 */
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 044a0dd..1926fb7 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -732,6 +732,7 @@ static int ping_v4_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
 	ipc.tos = -1;
 
 	sock_tx_timestamp(sk, &ipc.tx_flags);
+	ipc.tx_flags |= skbflags_tx_tstamp(msg->msg_flags);
 
 	if (msg->msg_controllen) {
 		err = ip_cmsg_send(sock_net(sk), msg, &ipc, false);
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 2c65160..ade2c8c 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -365,6 +365,9 @@ static int raw_send_hdrinc(struct sock *sk, struct flowi4 *fl4,
 
 	skb->ip_summed = CHECKSUM_NONE;
 
+	sock_tx_timestamp(sk, &skb_shinfo(skb)->tx_flags);
+	skb_shinfo(skb)->tx_flags |= skbflags_tx_tstamp(flags);
+
 	skb->transport_header = skb->network_header;
 	err = -EFAULT;
 	if (memcpy_fromiovecend((void *)iph, from, 0, length))
@@ -606,6 +609,9 @@ back_from_confirm:
 				      &rt, msg->msg_flags);
 
 	 else {
+		sock_tx_timestamp(sk, &ipc.tx_flags);
+		ipc.tx_flags |= skbflags_tx_tstamp(msg->msg_flags);
+
 		if (!ipc.addr)
 			ipc.addr = fl4.daddr;
 		lock_sock(sk);
-- 
2.0.0.526.g5318336

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Thu, Jul 03, 2014 at 03:39:33PM -0400, Willem de Bruijn wrote:

> +/**
> + *	struct scm_timestamping - timestamps exposed through cmsg
> + *
> + *	The timestamping interfaces SO_TIMESTAMPING, MSG_TSTAMP_*
> + *	communicate network timestamps by passing this struct in a cmsg with
> + *	recvmsg(). See Documentation/networking/timestamping.txt for details.
> + */
> +struct scm_timestamping {
> +	struct timespec ts[3];
> +};
> +
> +#define SCM_TSTAMP_SND		0x1	/* driver passed skb to NIC */
> +#define SCM_TSTAMP_ACK		0x2	/* transport layer saw ACK */
> +#define SCM_TSTAMP_ENQ		0x4	/* stack passed skb to TC layer */
> +#define SCM_TSTAMP_RCV		0x8	/* stack received skb */
> +#define SCM_TSTAMP_HWSYS	0x10	/* NIC tstamp in system format */
> +#define SCM_TSTAMP_HWRAW	0x20	/* NIC tstamp in native format */
> +
> +#define SCM_TSTAMP_OFF(n, ts)	(ts << (10 * n))

Hm ...
  
>  #endif /* _UAPI_LINUX_ERRQUEUE_H */
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index c1a3303..1bcd05d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3521,6 +3521,7 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
>  	memset(serr, 0, sizeof(*serr));
>  	serr->ee.ee_errno = ENOMSG;
>  	serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
> +	serr->ee.ee_info = hwtstamps ? 0 : SCM_TSTAMP_SND;
>  
>  	err = sock_queue_err_skb(sk, skb);
>  
> diff --git a/net/socket.c b/net/socket.c
> index abf56b2..a31138d 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -106,6 +106,7 @@
>  #include <linux/sockios.h>
>  #include <linux/atalk.h>
>  #include <net/busy_poll.h>
> +#include <linux/errqueue.h>
>  
>  #ifdef CONFIG_NET_RX_BUSY_POLL
>  unsigned int sysctl_net_busy_read __read_mostly;
> @@ -696,9 +697,10 @@ EXPORT_SYMBOL(kernel_sendmsg);
>  void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
>  	struct sk_buff *skb)
>  {
> +	struct sock_exterr_skb *serr = SKB_EXT_ERR(skb);
>  	int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
> -	struct timespec ts[3];
> -	int empty = 1;
> +	struct scm_timestamping tss;
> +	int tstype = 0, is_tx = skb_shinfo(skb)->tx_flags & SKBTX_ANY_TSTAMP;
>  	struct skb_shared_hwtstamps *shhwtstamps =
>  		skb_hwtstamps(skb);
>  
> @@ -714,28 +716,31 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
>  			put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMP,
>  				 sizeof(tv), &tv);
>  		} else {
> -			skb_get_timestampns(skb, &ts[0]);
> +			struct timespec ts;
> +			skb_get_timestampns(skb, &ts);
>  			put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPNS,
> -				 sizeof(ts[0]), &ts[0]);
> +				 sizeof(ts), &ts);
>  		}
>  	}
>  
> -
> -	memset(ts, 0, sizeof(ts));
> +	memset(&tss, 0, sizeof(tss));
>  	if (sock_flag(sk, SOCK_TIMESTAMPING_SOFTWARE) &&
> -	    ktime_to_timespec_cond(skb->tstamp, ts + 0))
> -		empty = 0;
> +	    ktime_to_timespec_cond(skb->tstamp, tss.ts + 0))
> +		tstype |= is_tx ? serr->ee.ee_info : SCM_TSTAMP_RCV;
>  	if (shhwtstamps) {
>  		if (sock_flag(sk, SOCK_TIMESTAMPING_SYS_HARDWARE) &&
> -		    ktime_to_timespec_cond(shhwtstamps->syststamp, ts + 1))
> -			empty = 0;
> +		    ktime_to_timespec_cond(shhwtstamps->syststamp, tss.ts + 1))
> +			tstype |= SCM_TSTAMP_OFF(1, SCM_TSTAMP_HWSYS);
>  		if (sock_flag(sk, SOCK_TIMESTAMPING_RAW_HARDWARE) &&
> -		    ktime_to_timespec_cond(shhwtstamps->hwtstamp, ts + 2))
> -			empty = 0;
> +		    ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2))
> +			tstype |= SCM_TSTAMP_OFF(2, SCM_TSTAMP_HWRAW);

So you want ee_info to be a bit field like this?

   | 10 bits    | 10 bits    | 10 bits    | 2 bits |
   |------------+------------+------------+--------|
   | ts[0] type | ts[1] type | ts[2] type | rsv    |

Why not simplify this into two fields:

1. the index ts[] that contains a time stamp
2. the type of the time stamp

The kernel never provides more than one value in ts[], and it is hard
to imagine that we will ever do this. The original so_timestamping
interface and documentation seem to suggest that multiple values are
possible, but there was never, ever any code that did this. As an end
user, I found that very confusing.

I would prefer making the extended interface simpler, rather than
giving the impression that multiple time stamps are possible when they
really are not.

Thanks,
Richard

>  	}
> -	if (!empty)
> +	if (tstype) {
> +		if (is_tx)
> +			serr->ee.ee_info = tstype;
>  		put_cmsg(msg, SOL_SOCKET,
> -			 SCM_TIMESTAMPING, sizeof(ts), &ts);
> +			 SCM_TIMESTAMPING, sizeof(tss), &tss);
> +	}
>  }
>  EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
>  
> -- 
> 2.0.0.526.g5318336
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v2 7/8] net-timestamp: expand documentation

[Richard Cochran]

On Thu, Jul 03, 2014 at 03:39:39PM -0400, Willem de Bruijn wrote:

> -hwtimetrans is the hardware time stamp transformed so that it
> +SCM_TSTAMP_HWRAW is the hardware time stamp transformed so that it
>  corresponds as good as possible to system time. This correlation is
>  not perfect; as a consequence, sorting packets received via different
>  NICs by their hwtimetrans may differ from the order in which they were

While we are at it, I would like to replace this text with something
like "legacy field, always zero."

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Thu, Jul 03, 2014 at 03:39:33PM -0400, Willem de Bruijn wrote:

> +#define SCM_TSTAMP_SND		0x1	/* driver passed skb to NIC */
> +#define SCM_TSTAMP_ACK		0x2	/* transport layer saw ACK */
> +#define SCM_TSTAMP_ENQ		0x4	/* stack passed skb to TC layer */
> +#define SCM_TSTAMP_RCV		0x8	/* stack received skb */
> +#define SCM_TSTAMP_HWSYS	0x10	/* NIC tstamp in system format */

We don't need this flag. Better to omit it, because we are not going
to allow this kind of time stamp ever again.

> +#define SCM_TSTAMP_HWRAW	0x20	/* NIC tstamp in native format */

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Willem de Bruijn]

On Sat, Jul 5, 2014 at 4:18 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Thu, Jul 03, 2014 at 03:39:33PM -0400, Willem de Bruijn wrote:
>
>> +#define SCM_TSTAMP_SND               0x1     /* driver passed skb to NIC */
>> +#define SCM_TSTAMP_ACK               0x2     /* transport layer saw ACK */
>> +#define SCM_TSTAMP_ENQ               0x4     /* stack passed skb to TC layer */
>> +#define SCM_TSTAMP_RCV               0x8     /* stack received skb */
>> +#define SCM_TSTAMP_HWSYS     0x10    /* NIC tstamp in system format */
>
> We don't need this flag. Better to omit it, because we are not going
> to allow this kind of time stamp ever again.

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?

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.

Better, that field in could be removed completely if there are no
users.That would be self documenting, would simplify plumbing
boilerplate and shrink sbk_shared_info.

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.

>> +#define SCM_TSTAMP_HWRAW     0x20    /* NIC tstamp in native format */
>
> Thanks,
> Richard

Re: [PATCH net-next v2 7/8] net-timestamp: expand documentation

[Willem de Bruijn]

On Sat, Jul 5, 2014 at 4:14 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Thu, Jul 03, 2014 at 03:39:39PM -0400, Willem de Bruijn wrote:
>
>> -hwtimetrans is the hardware time stamp transformed so that it
>> +SCM_TSTAMP_HWRAW is the hardware time stamp transformed so that it
>>  corresponds as good as possible to system time. This correlation is
>>  not perfect; as a consequence, sorting packets received via different
>>  NICs by their hwtimetrans may differ from the order in which they were
>
> While we are at it, I would like to replace this text with something
> like "legacy field, always zero."

Judging from the octeon code, it may be non-zero. Perhaps

"Deprecated field. It is always zero on all but one platform and not
supported for new platform development. Applications should not use
this field."
>
> Thanks,
> Richard
>

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

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

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Willem de Bruijn]

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

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Chad Reese]

On 07/07/2014 12:14 PM, Willem de Bruijn wrote:
> 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.

A hardware timer used for ethernet timestamps is completely independent 
from the kernel's software view of time. Since the hardware timestamps 
are only exposed in the driver, how can they be correlated with system 
time? If the driver doesn't do it, then nobody else knows how.

For Octeon, you can optionally use the hardware timestamp as the system 
clock reference. Most people don't, but it is the only way to get the 
system time to be accurate. 1588 can synchronize two Octeon boards to 
less than 1ns for the hardware timer. The Linux software timers is 
always farther off.

Chad

-- 

Chad Reese <kreese@cavium.com>
Cavium Networks
Phone: 408 - 943 - 7183
Cell: 321 - 438 - 7753

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Mon, Jul 07, 2014 at 12:44:44PM -0700, Chad Reese wrote:
> 
> A hardware timer used for ethernet timestamps is completely
> independent from the kernel's software view of time. Since the
> hardware timestamps are only exposed in the driver, how can they be
> correlated with system time? If the driver doesn't do it, then
> nobody else knows how.

Um, implement a PTP Hardware Clock device?

Don't reimplement clock servos in your driver. Instead, leave that to
the PTP stack (like using linuxptp's phc2sys).
 
> For Octeon, you can optionally use the hardware timestamp as the
> system clock reference. Most people don't, but it is the only way to
> get the system time to be accurate. 1588 can synchronize two Octeon
> boards to less than 1ns for the hardware timer. The Linux software
> timers is always farther off.

1588 cannot synchronize boards unless you expose the clock to the
userland PTP stack. Why don't you do that?

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Mon, Jul 07, 2014 at 12:44:44PM -0700, Chad Reese wrote:
> 
> For Octeon, you can optionally use the hardware timestamp as the
> system clock reference. Most people don't, but it is the only way to
> get the system time to be accurate. 1588 can synchronize two Octeon
> boards to less than 1ns for the hardware timer. The Linux software
> timers is always farther off.

Did you mean 1us ?

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Chad Reese]

On 07/07/2014 01:11 PM, Richard Cochran wrote:
> On Mon, Jul 07, 2014 at 12:44:44PM -0700, Chad Reese wrote:
>>
>> A hardware timer used for ethernet timestamps is completely
>> independent from the kernel's software view of time. Since the
>> hardware timestamps are only exposed in the driver, how can they be
>> correlated with system time? If the driver doesn't do it, then
>> nobody else knows how.
>
> Um, implement a PTP Hardware Clock device?

Octeon does support using the 1588 clock as the kernel's clock source. 
Unfortunately most people don't seem to want to use it. I have no idea why.

> Don't reimplement clock servos in your driver. Instead, leave that to
> the PTP stack (like using linuxptp's phc2sys).

I obviously did it wrong. The one line comment in 
Documentation/networking/timestamping.txt was not enough for me to 
figure out the proper usage of syststamp.

>> For Octeon, you can optionally use the hardware timestamp as the
>> system clock reference. Most people don't, but it is the only way to
>> get the system time to be accurate. 1588 can synchronize two Octeon
>> boards to less than 1ns for the hardware timer. The Linux software
>> timers is always farther off.
>
> 1588 cannot synchronize boards unless you expose the clock to the
> userland PTP stack. Why don't you do that?

I was trying to stick with standard linux userspace APIs. People have no 
interest in the PTP clock at all. All they want is for the standard 
system time to be correct.

Chad

-- 

Chad Reese <kreese@cavium.com>
Cavium Networks
Phone: 408 - 943 - 7183
Cell: 321 - 438 - 7753

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Chad Reese]

On 07/07/2014 01:18 PM, Richard Cochran wrote:
> On Mon, Jul 07, 2014 at 12:44:44PM -0700, Chad Reese wrote:
>>
>> For Octeon, you can optionally use the hardware timestamp as the
>> system clock reference. Most people don't, but it is the only way to
>> get the system time to be accurate. 1588 can synchronize two Octeon
>> boards to less than 1ns for the hardware timer. The Linux software
>> timers is always farther off.
>
> Did you mean 1us ?

No, it was 1ns. Who would go through all this effort if all you wanted 
was 1us?  Our requirement was within 20ns, but me managed to get 1ns 
with a lab setup. We had to be careful that the scope probes used in the 
measurement were the same length.

Chad

-- 

Chad Reese <kreese@cavium.com>
Cavium Networks
Phone: 408 - 943 - 7183
Cell: 321 - 438 - 7753

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Mon, Jul 07, 2014 at 02:08:57PM -0700, Chad Reese wrote:
> 
> No, it was 1ns. Who would go through all this effort if all you
> wanted was 1us?  Our requirement was within 20ns, but me managed to
> get 1ns with a lab setup. We had to be careful that the scope probes
> used in the measurement were the same length.

Well, in a lab, carefully compensating for phy delays, etc, etc,
achieving 1ns is one thing. As a general statement, telling the
public, "our PTP hardware synchronizes to within one nanosecond",
is quite another thing.

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Mon, Jul 07, 2014 at 02:03:38PM -0700, Chad Reese wrote:
> On 07/07/2014 01:11 PM, Richard Cochran wrote:
> >Don't reimplement clock servos in your driver. Instead, leave that to
> >the PTP stack (like using linuxptp's phc2sys).
> 
> I obviously did it wrong. The one line comment in
> Documentation/networking/timestamping.txt was not enough for me to
> figure out the proper usage of syststamp.

Sorry about not having clearly deprecated syststamp. We'll do that now.
Next time, putting the PTP maintainer on CC will help catch such things.
 
> I was trying to stick with standard linux userspace APIs.

There is a standard PTP hardware clock subsystem and API, as explained
in Documentation/ptp/ptp.txt.  

> People
> have no interest in the PTP clock at all. All they want is for the
> standard system time to be correct.

You can't have the time correct unless you synchronize it to
something. That is what NTP and PTP are all about. When using a PTP
hardware clock, it is necessary to synchronize the Linux system time
to it. The right way to accomplish this is using a userland PTP
stack, and the wrong way is to implement a servo in every last MAC
driver.

What I don't understand is, how does your device get the PTP time
without running the PTP protocol?

How can your device work without implementing a PTP clock? What am I
missing?

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Tue, Jul 08, 2014 at 07:49:19AM +0200, Richard Cochran wrote:
> On Mon, Jul 07, 2014 at 02:08:57PM -0700, Chad Reese wrote:
> > 
> > No, it was 1ns. Who would go through all this effort if all you
> > wanted was 1us?  Our requirement was within 20ns, but me managed to
> > get 1ns with a lab setup. We had to be careful that the scope probes
> > used in the measurement were the same length.
> 
> Well, in a lab, carefully compensating for phy delays, etc, etc,
> achieving 1ns is one thing. As a general statement, telling the
> public, "our PTP hardware synchronizes to within one nanosecond",
> is quite another thing.

And you are using synchronous Ethernet, too, I suppose?

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Chad Reese]

On 07/07/2014 11:04 PM, Richard Cochran wrote:
> On Mon, Jul 07, 2014 at 02:03:38PM -0700, Chad Reese wrote:
>> On 07/07/2014 01:11 PM, Richard Cochran wrote:
>>> Don't reimplement clock servos in your driver. Instead, leave that to
>>> the PTP stack (like using linuxptp's phc2sys).
>>
>> I obviously did it wrong. The one line comment in
>> Documentation/networking/timestamping.txt was not enough for me to
>> figure out the proper usage of syststamp.
>
> Sorry about not having clearly deprecated syststamp. We'll do that now.
> Next time, putting the PTP maintainer on CC will help catch such things.
>
>> I was trying to stick with standard linux userspace APIs.
>
> There is a standard PTP hardware clock subsystem and API, as explained
> in Documentation/ptp/ptp.txt.
>
>> People
>> have no interest in the PTP clock at all. All they want is for the
>> standard system time to be correct.
>
> You can't have the time correct unless you synchronize it to
> something. That is what NTP and PTP are all about. When using a PTP
> hardware clock, it is necessary to synchronize the Linux system time
> to it. The right way to accomplish this is using a userland PTP
> stack, and the wrong way is to implement a servo in every last MAC
> driver.

You keep saying I implemented a clock servo in the MAC driver. I didn't, 
as is apparent in the code. The only kludge was a conversion from the 
PTP clock to system time with a simple offset function. I will fully 
admit it wasn't great, but it was good enough.

> What I don't understand is, how does your device get the PTP time
> without running the PTP protocol?

I wrote a PTPv2 daemon for Cavium that ran in userspace. It implemented 
all the v2 spec with support for both IP and 802.3 transport. This was 
done from scratch as there wasn't an opensource PTPv2 daemon at the 
time. All this work actually started before there was any PTP timestamp 
support in the kernel. I originally started writing PTP to run on bare 
metal.

> How can your device work without implementing a PTP clock? What am I
> missing?

I'm guessing the details of our PTP implementation are not available to 
the opensource community. It was packaged as a product by Cavium's 
marketing along with other software to support base stations.

Chad

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Richard Cochran]

On Tue, Jul 08, 2014 at 12:42:46AM -0700, Chad Reese wrote:
> 
> You keep saying I implemented a clock servo in the MAC driver. I
> didn't, as is apparent in the code. The only kludge was a conversion
> from the PTP clock to system time with a simple offset function. I
> will fully admit it wasn't great, but it was good enough.

I assume that the point of providing both raw and sys time stamps was
to discipline the Linux system clock to the raw clock. (Otherwise, what
good are the sys values?)

In that case, the sample rate is a result of the packet activity in
the driver, and the rate is a part of the servo, at least to my
understanding.
 
> I wrote a PTPv2 daemon for Cavium that ran in userspace. It
> implemented all the v2 spec with support for both IP and 802.3
> transport. This was done from scratch as there wasn't an opensource
> PTPv2 daemon at the time. All this work actually started before
> there was any PTP timestamp support in the kernel. I originally
> started writing PTP to run on bare metal.

Okay, that is now clear. There is nothing wrong with that, although it
is too bad you cannot use the newer interface.

So, the question becomes, will removing the sys time stamp from the
octeon driver spoil your application?

[ The octeon time stamping was merged in August 2012, well after the
  PTP support which appeared in April 2011. So I guess that your
  custom application doesn't need the dual time stamps. ]

Thanks,
Richard

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Willem de Bruijn]

> So, the question becomes, will removing the sys time stamp from the
> octeon driver spoil your application?

Chad? If it cannot be removed easily, I will prepare the temporary
documentation patch to mark the field as deprecated.

On the topic of this original patch: I'll remove SCM_TSTAMP_HWSYS
and will simplify ee_info to only hold a type. No need for an explicit
index field if we simply assume that the ts[] index is always 0, except
for SCM_TSTAMP_HW, which is 2. We can even copy that one into
both fields 0 and 2 and consider the latter as a legacy workaround.

Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct

[Willem de Bruijn]

On Sat, Jul 5, 2014 at 4:10 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Thu, Jul 03, 2014 at 03:39:33PM -0400, Willem de Bruijn wrote:
>
>> +struct scm_timestamping {
>> +     struct timespec ts[3];
>> +};
>> +
>> +#define SCM_TSTAMP_SND               0x1     /* driver passed skb to NIC */
>> +#define SCM_TSTAMP_ACK               0x2     /* transport layer saw ACK */
>> +#define SCM_TSTAMP_ENQ               0x4     /* stack passed skb to TC layer */
>> +#define SCM_TSTAMP_RCV               0x8     /* stack received skb */
>> +#define SCM_TSTAMP_HWSYS     0x10    /* NIC tstamp in system format */
>> +#define SCM_TSTAMP_HWRAW     0x20    /* NIC tstamp in native format */
>> +
>> +#define SCM_TSTAMP_OFF(n, ts)        (ts << (10 * n))
>
> Hm ...
>

> So you want ee_info to be a bit field like this?
>
>    | 10 bits    | 10 bits    | 10 bits    | 2 bits |
>    |------------+------------+------------+--------|
>    | ts[0] type | ts[1] type | ts[2] type | rsv    |
>
> Why not simplify this into two fields:
>
> 1. the index ts[] that contains a time stamp
> 2. the type of the time stamp
>
> The kernel never provides more than one value in ts[], and it is hard
> to imagine that we will ever do this. The original so_timestamping
> interface and documentation seem to suggest that multiple values are
> possible, but there was never, ever any code that did this. As an end
> user, I found that very confusing.
>
> I would prefer making the extended interface simpler, rather than
> giving the impression that multiple time stamps are possible when they
> really are not.

Agreed. I have a simpler patchset ready where ee_info only
defines contents of ts[0] and the SCM fields are just an enum.

Before I send the entire patchset again, I plan to simplify two
other parts if no one objects.

1. only one MSG_TSTAMP send() flag.

The socket flag space is limited, so defining a flag for
each type of timestamp is not practical. Instead, define one flag
MSG_TSTAMP that generates all timestamps by default. The
default can be overridden at the socket level with timestamping
option fields such as SOF_TIMESTAMPING_ENQ_SOFTWARE.

2. correlate tstamps with data

If multiple datagrams are in flight, it is ambiguous to which
datagram a timestamp refers. The payload is looped with the
timestamp, but content-based correlation can be expensive,
even impossible.

My previous patch addressed this for TCP only, by passing
a seqno in ee_data. That has issues of its own. For one, with
write_seq at send time not know to the process, it is still hard
to correlate. I am going to remove that.

Returning a counter in ee_data to distinguish tstamps from
successive send(.., MSG_TSTAMP) calls allows correlation.
Better is if it works for all protocols. An explicit per-sk counter
+ per-skb id field would require scarce skb space. Instead.
I plan to just loop skb->mark and leave it to the application to
choose marks wisely.

Re: net-timestamp: MSG_TSTAMP flags and bytestream support

[Willem de Bruijn]

Thanks for taking a look, Richard. I will reply inline to the individual emails.

On Wed, Jun 25, 2014 at 3:32 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Jun 24, 2014 at 11:43:45AM -0400, Willem de Bruijn wrote:
>> This patchset extends socket timestamping in a number of related ways.
>> Most notably:
>>
>> 2 MSG_TSTAMP: request a single tx timestamp by passing a flag on send
>> 6 MSG_TSTAMP_ENQ: request a tx timestamp before traffic shaping.
>> 5 MSG_TSTAMP_ACK: request a tx timestamp after acknowledgements (TCP)
>> 4 TCP support for all three flags
>
> Can you tell us a bit about the use case?  It sounds like that this is
> for performance monitoring.

There are a couple of use cases: 24/7 sampled background monitoring,
detailed analysis of (tail) latency and application delivery
notifications, for example.

The MSG flags enable sampled measurement, both random sampling for the
first use case, and explicit communication of application data unit
delimiters to the kernel in the case of bytestreams. It is quite
common to embed discrete message protocols in a TCP stream to gain
reliability, flow control, ... In that case, only the send() call that
writes the final byte of a message will generate a timestamp that is
relevant to the application.

The new measurement points are indeed for performance monitoring,
specifically for debugging of tail latency root causes. Traffic
shaping, TCP pacing, byte queue limits and other queuing can affect
latency. Measurement points along the skb lifecycle help pinpoint the
specific root cause.

>> Each individual patch commit message gives more detail about the
>> specific feature.
>>
>> The other patches support the main feature:
>> 1 explicitly define the timestamp response API
>> 3 optionally avoid looping large packets onto the socket error queue.
>> 7 documentation and an example test.
>
> I think #2 and #3 could be improvements to the so_timestamping api.
>
> The others probably need their own, separate api. I can't imagine
> wanting to mix so_timestamping with these new tcp time stamps, but
> maybe you want to explain the expected scenario?

I think that a single coherent timestamping API would be better than a
fragmented experience with disjoint feature set. Both depend
internally on the same SKBTX_.. flags and the same skb_tstamp_tx
plumbing. I think that they should also implement the same set feature
set and return timestamps in the same format (where possible given
legacy API constraints).

This requires extensions to both to cover the other's feature set,
e.g., MSG_TSTAMP_HW and SOF_TIMESTAMPING_TX_ENQUEUE. But those are
minor changes. I'd be happy to work on those as follow on work.




>
> Thanks,
> Richard

Re: net-timestamp: MSG_TSTAMP flags and bytestream support

[Richard Cochran]

On Tue, Jun 24, 2014 at 11:43:45AM -0400, Willem de Bruijn wrote:
> This patchset extends socket timestamping in a number of related ways.
> Most notably:
> 
> 2 MSG_TSTAMP: request a single tx timestamp by passing a flag on send
> 6 MSG_TSTAMP_ENQ: request a tx timestamp before traffic shaping.
> 5 MSG_TSTAMP_ACK: request a tx timestamp after acknowledgements (TCP)
> 4 TCP support for all three flags

Can you tell us a bit about the use case?  It sounds like that this is
for performance monitoring.

> Each individual patch commit message gives more detail about the
> specific feature.
> 
> The other patches support the main feature:
> 1 explicitly define the timestamp response API
> 3 optionally avoid looping large packets onto the socket error queue.
> 7 documentation and an example test.

I think #2 and #3 could be improvements to the so_timestamping api.

The others probably need their own, separate api. I can't imagine
wanting to mix so_timestamping with these new tcp time stamps, but
maybe you want to explain the expected scenario?

Thanks,
Richard

net-timestamp: MSG_TSTAMP flags and bytestream support

[Willem de Bruijn]

This patchset extends socket timestamping in a number of related ways.
Most notably:

2 MSG_TSTAMP: request a single tx timestamp by passing a flag on send
6 MSG_TSTAMP_ENQ: request a tx timestamp before traffic shaping.
5 MSG_TSTAMP_ACK: request a tx timestamp after acknowledgements (TCP)
4 TCP support for all three flags

Each individual patch commit message gives more detail about the
specific feature.

The other patches support the main feature:
1 explicitly define the timestamp response API
3 optionally avoid looping large packets onto the socket error queue.
7 documentation and an example test.

This initial patchset is mostly to request feedback. Though the
patches are somewhat interdependent, I can resubmit them independently
or drop optional features (most notably, patches 1 and 3).

While rebasing, I found a few possible improvements, myself. These are
debatable, so I will send the set first and optionally integrate these
in v2:

- The struct in patch 1 was informally called scm_timestamping in the
  documentation. I prefer that name over the long one I came up with.
- We can actually avoid extending that structure, because ts_type and
  ts_key can be passed in the currently unused sock_extended_err
  fields ee_info and ee_data
- the new functionality of MSG_TSTAMP_* should also be extended to
  the socket option interface SO_TIMESTAMPING

Tested:
  I ran the msg_tstamp binary for various settings:
  - IPv4 and IPv6
  - UDP and TCP
  - 1 B and 20 KB payload
  - GSO, TSO, neither
  - with and without the no-payload feature (patch 3)

  Example output from one IPv4/TCP/1B/payload run:
  (on a bonded machine, resulting in 2 ENQ timestamps per send)

proto INET
  test SND
      USR: 1400265321 s 167847 us (seq=0, len=0)
      SND: 1400265321 s 167854 us (seq=408779523, len=7)  (+7 us)
  test ENQ
      USR: 1400265321 s 768728 us (seq=0, len=7)
      ENQ: 1400265321 s 768732 us (seq=3113669987, len=7)  (+4 us)
      ENQ: 1400265321 s 768734 us (seq=3113669987, len=7)  (+2 us)
  test ENQ + SND
      USR: 1400265322 s 369747 us (seq=0, len=7)
      ENQ: 1400265322 s 369750 us (seq=2305548511, len=7)  (+3 us)
      ENQ: 1400265322 s 369751 us (seq=2305548511, len=7)  (+1 us)
      SND: 1400265322 s 369752 us (seq=2305548511, len=7)  (+1 us)
  test ACK
      USR: 1400265322 s 970717 us (seq=0, len=7)
      ACK: 1400265322 s 970752 us (seq=2324323855, len=7)  (+35 us)
  test SND + ACK
      USR: 1400265323 s 571662 us (seq=0, len=7)
      SND: 1400265323 s 571681 us (seq=872301729, len=7)  (+19 us)
      ACK: 1400265323 s 571708 us (seq=872301729, len=7)  (+27 us)
  test ENQ + SND + ACK
      USR: 1400265324 s 172558 us (seq=0, len=7)
      ENQ: 1400265324 s 172561 us (seq=2135092223, len=7)  (+3 us)
      ENQ: 1400265324 s 172565 us (seq=2135092223, len=7)  (+4 us)
      SND: 1400265324 s 172581 us (seq=2135092223, len=7)  (+16 us)
      ACK: 1400265324 s 172624 us (seq=2135092223, len=7)  (+43 us)


Signed-off-by: Willem de Bruijn <willemb@google.com>