netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next v3 0/3] net: A lightweight zero-copy notification
@ 2024-05-10 15:58 zijianzhang
  2024-05-10 15:58 ` [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest zijianzhang
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: zijianzhang @ 2024-05-10 15:58 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

From: Zijian Zhang <zijianzhang@bytedance.com>

Original title is "net: socket sendmsg MSG_ZEROCOPY_UARG". 

Original notification mechanism needs poll + recvmmsg which is not
easy for applcations to accommodate. And, it also incurs unignorable
overhead including extra system calls and usage of optmem.

While making maximum reuse of the existing MSG_ZEROCOPY related code,
this patch set introduces a new zerocopy socket notification mechanism.
Users of sendmsg pass a control message as a placeholder for the incoming
notifications. Upon returning, kernel embeds notifications directly into
user arguments passed in. By doing so, we can significantly reduce the
complexity and overhead for managing notifications. In an ideal pattern,
the user will keep calling sendmsg with SCM_ZC_NOTIFICATION msg_control,
and the notification will be delivered as soon as possible.

Changelog:
  v1 -> v2:
    - Reuse errormsg queue in the new notification mechanism,
      users can actually use these two mechanisms in hybrid way
      if they want to do so.
    - Update case SCM_ZC_NOTIFICATION in __sock_cmsg_send
      1. Regardless of 32-bit, 64-bit program, we will always handle
      u64 type user address.
      2. The size of data to copy_to_user is precisely calculated
      in case of kernel stack leak.
    - fix (kbuild-bot)
      1. Add SCM_ZC_NOTIFICATION to arch-specific header files.
      2. header file types.h in include/uapi/linux/socket.h

  v2 -> v3:
    - 1. Users can now pass in the address of the zc_info_elem directly
      with appropriate cmsg_len instead of the ugly user interface. Plus,
      the handler is now compatible with MSG_CMSG_COMPAT and 32-bit
      pointer.
    - 2. Suggested by Willem, another strategy of getting zc info is
      briefly taking the lock of sk_error_queue and move to a private
      list, like net_rx_action. I thought sk_error_queue is protected by
      sock_lock, so that it's impossible for the handling of zc info and
      users recvmsg from the sk_error_queue at the same time.
      However, sk_error_queue is protected by its own lock. I am afraid
      that during the time it is handling the private list, users may
      fail to get other error messages in the queue via recvmsg. Thus,
      I don't implement the splice logic in this version. Any comments?


* Performance

I extend the selftests/msg_zerocopy.c to accommodate the new mechanism,
test result is as follows,

cfg_notification_limit = 1, in this case the original method approximately
aligns with the semantics of new one. In this case, the new flag has
around 13% cpu savings in TCP and 18% cpu savings in UDP.

+---------------------+---------+---------+---------+---------+
| Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
+---------------------+---------+---------+---------+---------+
| ZCopy (MB)          | 5147    | 4885    | 7489    | 7854    |
+---------------------+---------+---------+---------+---------+
| New ZCopy (MB)      | 5859    | 5505    | 9053    | 9236    |
+---------------------+---------+---------+---------+---------+
| New ZCopy / ZCopy   | 113.83% | 112.69% | 120.88% | 117.59% |
+---------------------+---------+---------+---------+---------+


cfg_notification_limit = 32, the new mechanism performs 8% better in TCP.
For UDP, no obvious performance gain is observed and sometimes may lead
to degradation. Thus, if users don't need to retrieve the notification
ASAP in UDP, the original mechanism is preferred.

+---------------------+---------+---------+---------+---------+
| Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
+---------------------+---------+---------+---------+---------+
| ZCopy (MB)          | 6272    | 6138    | 12138   | 10055   |
+---------------------+---------+---------+---------+---------+
| New ZCopy (MB)      | 6774    | 6620    | 11504   | 10355   |
+---------------------+---------+---------+---------+---------+
| New ZCopy / ZCopy   | 108.00% | 107.85% | 94.78%  | 102.98% |
+---------------------+---------+---------+---------+---------+

Zijian Zhang (3):
  selftests: fix OOM problem in msg_zerocopy selftest
  sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  selftests: add MSG_ZEROCOPY msg_control notification test

 arch/alpha/include/uapi/asm/socket.h        |   2 +
 arch/mips/include/uapi/asm/socket.h         |   2 +
 arch/parisc/include/uapi/asm/socket.h       |   2 +
 arch/sparc/include/uapi/asm/socket.h        |   2 +
 include/uapi/asm-generic/socket.h           |   2 +
 include/uapi/linux/socket.h                 |  10 ++
 net/core/sock.c                             |  68 ++++++++++++
 tools/testing/selftests/net/msg_zerocopy.c  | 114 ++++++++++++++++++--
 tools/testing/selftests/net/msg_zerocopy.sh |   1 +
 9 files changed, 196 insertions(+), 7 deletions(-)

-- 
2.20.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest
  2024-05-10 15:58 [PATCH net-next v3 0/3] net: A lightweight zero-copy notification zijianzhang
@ 2024-05-10 15:58 ` zijianzhang
  2024-05-13  0:47   ` Willem de Bruijn
  2024-05-10 15:58 ` [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control zijianzhang
  2024-05-10 15:59 ` [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test zijianzhang
  2 siblings, 1 reply; 10+ messages in thread
From: zijianzhang @ 2024-05-10 15:58 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

From: Zijian Zhang <zijianzhang@bytedance.com>

In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg
on a socket with MSG_ZEROCOPY flag, and it will recv the notifications
until the socket is not writable. Typically, it will start the receiving
process after around 30+ sendmsgs. However, because of the
commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale")
the sender is always writable and does not get any chance to run recv
notifications. The selftest always exits with OUT_OF_MEMORY because the
memory used by opt_skb exceeds the core.sysctl_optmem_max.

According to our experiments, this problem can be mitigated by open the
DEBUG_LOCKDEP configuration for the kernel. But it will makes the
notifications disordered even in good commits before
commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale").

We introduce "cfg_notification_limit" to force sender to receive
notifications after some number of sendmsgs. And, notifications may not
come in order, because of the reason we present above. We have order
checking code managed by cfg_verbose.

Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
---
 tools/testing/selftests/net/msg_zerocopy.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/net/msg_zerocopy.c b/tools/testing/selftests/net/msg_zerocopy.c
index bdc03a2097e8..ba6c257f689c 100644
--- a/tools/testing/selftests/net/msg_zerocopy.c
+++ b/tools/testing/selftests/net/msg_zerocopy.c
@@ -85,6 +85,7 @@ static bool cfg_rx;
 static int  cfg_runtime_ms	= 4200;
 static int  cfg_verbose;
 static int  cfg_waittime_ms	= 500;
+static int  cfg_notification_limit = 32;
 static bool cfg_zerocopy;
 
 static socklen_t cfg_alen;
@@ -95,6 +96,8 @@ static char payload[IP_MAXPACKET];
 static long packets, bytes, completions, expected_completions;
 static int  zerocopied = -1;
 static uint32_t next_completion;
+/* The number of sendmsgs which have not received notified yet */
+static uint32_t sendmsg_counter;
 
 static unsigned long gettimeofday_ms(void)
 {
@@ -208,6 +211,7 @@ static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
 		error(1, errno, "send");
 	if (cfg_verbose && ret != len)
 		fprintf(stderr, "send: ret=%u != %u\n", ret, len);
+	sendmsg_counter++;
 
 	if (len) {
 		packets++;
@@ -435,7 +439,7 @@ static bool do_recv_completion(int fd, int domain)
 	/* Detect notification gaps. These should not happen often, if at all.
 	 * Gaps can occur due to drops, reordering and retransmissions.
 	 */
-	if (lo != next_completion)
+	if (cfg_verbose && lo != next_completion)
 		fprintf(stderr, "gap: %u..%u does not append to %u\n",
 			lo, hi, next_completion);
 	next_completion = hi + 1;
@@ -460,6 +464,7 @@ static bool do_recv_completion(int fd, int domain)
 static void do_recv_completions(int fd, int domain)
 {
 	while (do_recv_completion(fd, domain)) {}
+	sendmsg_counter = 0;
 }
 
 /* Wait for all remaining completions on the errqueue */
@@ -549,6 +554,9 @@ static void do_tx(int domain, int type, int protocol)
 		else
 			do_sendmsg(fd, &msg, cfg_zerocopy, domain);
 
+		if (cfg_zerocopy && sendmsg_counter >= cfg_notification_limit)
+			do_recv_completions(fd, domain);
+
 		while (!do_poll(fd, POLLOUT)) {
 			if (cfg_zerocopy)
 				do_recv_completions(fd, domain);
@@ -708,7 +716,7 @@ static void parse_opts(int argc, char **argv)
 
 	cfg_payload_len = max_payload_len;
 
-	while ((c = getopt(argc, argv, "46c:C:D:i:mp:rs:S:t:vz")) != -1) {
+	while ((c = getopt(argc, argv, "46c:C:D:i:l:mp:rs:S:t:vz")) != -1) {
 		switch (c) {
 		case '4':
 			if (cfg_family != PF_UNSPEC)
@@ -736,6 +744,9 @@ static void parse_opts(int argc, char **argv)
 			if (cfg_ifindex == 0)
 				error(1, errno, "invalid iface: %s", optarg);
 			break;
+		case 'l':
+			cfg_notification_limit = strtoul(optarg, NULL, 0);
+			break;
 		case 'm':
 			cfg_cork_mixed = true;
 			break;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  2024-05-10 15:58 [PATCH net-next v3 0/3] net: A lightweight zero-copy notification zijianzhang
  2024-05-10 15:58 ` [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest zijianzhang
@ 2024-05-10 15:58 ` zijianzhang
  2024-05-11  5:30   ` kernel test robot
  2024-05-13  0:58   ` Willem de Bruijn
  2024-05-10 15:59 ` [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test zijianzhang
  2 siblings, 2 replies; 10+ messages in thread
From: zijianzhang @ 2024-05-10 15:58 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

From: Zijian Zhang <zijianzhang@bytedance.com>

The MSG_ZEROCOPY flag enables copy avoidance for socket send calls.
However, zerocopy is not a free lunch. Apart from the management of user
pages, the combination of poll + recvmsg to receive notifications incurs
unignorable overhead in the applications. The overhead of such sometimes
might be more than the CPU savings from zerocopy. We try to solve this
problem with a new notification mechanism based on msgcontrol.
This new mechanism aims to reduce the overhead associated with receiving
notifications by embedding them directly into user arguments passed with
each sendmsg control message. By doing so, we can significantly reduce
the complexity and overhead for managing notifications. In an ideal
pattern, the user will keep calling sendmsg with SCM_ZC_NOTIFICATION
msg_control, and the notification will be delivered as soon as possible.

Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
---
 arch/alpha/include/uapi/asm/socket.h  |  2 +
 arch/mips/include/uapi/asm/socket.h   |  2 +
 arch/parisc/include/uapi/asm/socket.h |  2 +
 arch/sparc/include/uapi/asm/socket.h  |  2 +
 include/uapi/asm-generic/socket.h     |  2 +
 include/uapi/linux/socket.h           | 10 ++++
 net/core/sock.c                       | 68 +++++++++++++++++++++++++++
 7 files changed, 88 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index e94f621903fe..7761a4e0ea2c 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -140,6 +140,8 @@
 #define SO_PASSPIDFD		76
 #define SO_PEERPIDFD		77
 
+#define SCM_ZC_NOTIFICATION 78
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 60ebaed28a4c..89edc51380f0 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -151,6 +151,8 @@
 #define SO_PASSPIDFD		76
 #define SO_PEERPIDFD		77
 
+#define SCM_ZC_NOTIFICATION 78
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index be264c2b1a11..2911b43e6a9d 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -132,6 +132,8 @@
 #define SO_PASSPIDFD		0x404A
 #define SO_PEERPIDFD		0x404B
 
+#define SCM_ZC_NOTIFICATION 0x404C
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 682da3714686..dc045e87cc8e 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -133,6 +133,8 @@
 #define SO_PASSPIDFD             0x0055
 #define SO_PEERPIDFD             0x0056
 
+#define SCM_ZC_NOTIFICATION 0x0057
+
 #if !defined(__KERNEL__)
 
 
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 8ce8a39a1e5f..7474c8a244bc 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -135,6 +135,8 @@
 #define SO_PASSPIDFD		76
 #define SO_PEERPIDFD		77
 
+#define SCM_ZC_NOTIFICATION 78
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64 || (defined(__x86_64__) && defined(__ILP32__))
diff --git a/include/uapi/linux/socket.h b/include/uapi/linux/socket.h
index d3fcd3b5ec53..15cec8819f34 100644
--- a/include/uapi/linux/socket.h
+++ b/include/uapi/linux/socket.h
@@ -2,6 +2,8 @@
 #ifndef _UAPI_LINUX_SOCKET_H
 #define _UAPI_LINUX_SOCKET_H
 
+#include <linux/types.h>
+
 /*
  * Desired design of maximum size and alignment (see RFC2553)
  */
@@ -35,4 +37,12 @@ struct __kernel_sockaddr_storage {
 #define SOCK_TXREHASH_DISABLED	0
 #define SOCK_TXREHASH_ENABLED	1
 
+#define SOCK_ZC_INFO_MAX 128
+
+struct zc_info_elem {
+	__u32 lo;
+	__u32 hi;
+	__u8 zerocopy;
+};
+
 #endif /* _UAPI_LINUX_SOCKET_H */
diff --git a/net/core/sock.c b/net/core/sock.c
index 8d6e638b5426..15da609be026 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2842,6 +2842,74 @@ int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
 	case SCM_RIGHTS:
 	case SCM_CREDENTIALS:
 		break;
+	case SCM_ZC_NOTIFICATION: {
+		int ret, i = 0;
+		int cmsg_data_len, zc_info_elem_num;
+		void __user	*usr_addr;
+		struct zc_info_elem zc_info_kern[SOCK_ZC_INFO_MAX];
+		unsigned long flags;
+		struct sk_buff_head *q, local_q;
+		struct sk_buff *skb, *tmp;
+		struct sock_exterr_skb *serr;
+
+		if (!sock_flag(sk, SOCK_ZEROCOPY) || sk->sk_family == PF_RDS)
+			return -EINVAL;
+
+		cmsg_data_len = cmsg->cmsg_len - sizeof(struct cmsghdr);
+		if (cmsg_data_len % sizeof(struct zc_info_elem))
+			return -EINVAL;
+
+		zc_info_elem_num = cmsg_data_len / sizeof(struct zc_info_elem);
+		if (!zc_info_elem_num || zc_info_elem_num > SOCK_ZC_INFO_MAX)
+			return -EINVAL;
+
+		if (in_compat_syscall())
+			usr_addr = compat_ptr(*(compat_uptr_t *)CMSG_DATA(cmsg));
+		else
+			usr_addr = (void __user *)*(void **)CMSG_DATA(cmsg);
+		if (!access_ok(usr_addr, cmsg_data_len))
+			return -EFAULT;
+
+		q = &sk->sk_error_queue;
+		skb_queue_head_init(&local_q);
+		spin_lock_irqsave(&q->lock, flags);
+		skb = skb_peek(q);
+		while (skb && i < zc_info_elem_num) {
+			struct sk_buff *skb_next = skb_peek_next(skb, q);
+
+			serr = SKB_EXT_ERR(skb);
+			if (serr->ee.ee_errno == 0 &&
+			    serr->ee.ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
+				zc_info_kern[i].hi = serr->ee.ee_data;
+				zc_info_kern[i].lo = serr->ee.ee_info;
+				zc_info_kern[i].zerocopy = !(serr->ee.ee_code
+								& SO_EE_CODE_ZEROCOPY_COPIED);
+				__skb_unlink(skb, q);
+				__skb_queue_tail(&local_q, skb);
+				i++;
+			}
+			skb = skb_next;
+		}
+		spin_unlock_irqrestore(&q->lock, flags);
+
+		ret = copy_to_user(usr_addr,
+				   zc_info_kern,
+					i * sizeof(struct zc_info_elem));
+
+		if (unlikely(ret)) {
+			spin_lock_irqsave(&q->lock, flags);
+			skb_queue_reverse_walk_safe(&local_q, skb, tmp) {
+				__skb_unlink(skb, &local_q);
+				__skb_queue_head(q, skb);
+			}
+			spin_unlock_irqrestore(&q->lock, flags);
+			return -EFAULT;
+		}
+
+		while ((skb = __skb_dequeue(&local_q)))
+			consume_skb(skb);
+		break;
+	}
 	default:
 		return -EINVAL;
 	}
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test
  2024-05-10 15:58 [PATCH net-next v3 0/3] net: A lightweight zero-copy notification zijianzhang
  2024-05-10 15:58 ` [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest zijianzhang
  2024-05-10 15:58 ` [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control zijianzhang
@ 2024-05-10 15:59 ` zijianzhang
  2024-05-13  1:02   ` Willem de Bruijn
  2 siblings, 1 reply; 10+ messages in thread
From: zijianzhang @ 2024-05-10 15:59 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

From: Zijian Zhang <zijianzhang@bytedance.com>

We update selftests/net/msg_zerocopy.c to accommodate the new mechanism.

Test result from selftests/net/msg_zerocopy.c,
cfg_notification_limit = 1, in this case MSG_ZEROCOPY approximately
aligns with the semantics of MSG_ZEROCOPY_UARG. In this case, the new
flag has around 13% cpu savings in TCP and 18% cpu savings in UDP.
+---------------------+---------+---------+---------+---------+
| Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
+---------------------+---------+---------+---------+---------+
| ZCopy (MB)          | 5147    | 4885    | 7489    | 7854    |
+---------------------+---------+---------+---------+---------+
| New ZCopy (MB)      | 5859    | 5505    | 9053    | 9236    |
+---------------------+---------+---------+---------+---------+
| New ZCopy / ZCopy   | 113.83% | 112.69% | 120.88% | 117.59% |
+---------------------+---------+---------+---------+---------+

cfg_notification_limit = 32, it means less poll + recvmsg overhead,
the new mechanism performs 8% better in TCP. For UDP, no obvious
performance gain is observed and sometimes may lead to degradation.
Thus, if users don't need to retrieve the notification ASAP in UDP,
the original mechanism is preferred.
+---------------------+---------+---------+---------+---------+
| Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
+---------------------+---------+---------+---------+---------+
| ZCopy (MB)          | 6272    | 6138    | 12138   | 10055   |
+---------------------+---------+---------+---------+---------+
| New ZCopy (MB)      | 6774    | 6620    | 11504   | 10355   |
+---------------------+---------+---------+---------+---------+
| New ZCopy / ZCopy   | 108.00% | 107.85% | 94.78%  | 102.98% |
+---------------------+---------+---------+---------+---------+

Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
---
 tools/testing/selftests/net/msg_zerocopy.c  | 103 ++++++++++++++++++--
 tools/testing/selftests/net/msg_zerocopy.sh |   1 +
 2 files changed, 97 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/net/msg_zerocopy.c b/tools/testing/selftests/net/msg_zerocopy.c
index ba6c257f689c..48750a7a162c 100644
--- a/tools/testing/selftests/net/msg_zerocopy.c
+++ b/tools/testing/selftests/net/msg_zerocopy.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /* Evaluate MSG_ZEROCOPY
  *
  * Send traffic between two processes over one of the supported
@@ -66,6 +67,10 @@
 #define SO_ZEROCOPY	60
 #endif
 
+#ifndef SCM_ZC_NOTIFICATION
+#define SCM_ZC_NOTIFICATION	78
+#endif
+
 #ifndef SO_EE_CODE_ZEROCOPY_COPIED
 #define SO_EE_CODE_ZEROCOPY_COPIED	1
 #endif
@@ -74,6 +79,13 @@
 #define MSG_ZEROCOPY	0x4000000
 #endif
 
+#define ZC_MSGERR_NOTIFICATION 1
+#define ZC_MSGCTL_NOTIFICATION 2
+
+#define SOCK_ZC_INFO_NUM 8
+
+#define INVALID_ZEROCOPY_VAL 2
+
 static int  cfg_cork;
 static bool cfg_cork_mixed;
 static int  cfg_cpu		= -1;		/* default: pin to last cpu */
@@ -86,13 +98,16 @@ static int  cfg_runtime_ms	= 4200;
 static int  cfg_verbose;
 static int  cfg_waittime_ms	= 500;
 static int  cfg_notification_limit = 32;
-static bool cfg_zerocopy;
+static int  cfg_zerocopy;           /* Either 1 or 2, mode for SO_ZEROCOPY */
 
 static socklen_t cfg_alen;
 static struct sockaddr_storage cfg_dst_addr;
 static struct sockaddr_storage cfg_src_addr;
 
 static char payload[IP_MAXPACKET];
+static struct zc_info_elem zc_info[SOCK_ZC_INFO_NUM];
+static char zc_ckbuf[CMSG_SPACE(sizeof(void *))];
+static struct zc_info_elem *zc_info_ptr = zc_info;
 static long packets, bytes, completions, expected_completions;
 static int  zerocopied = -1;
 static uint32_t next_completion;
@@ -170,6 +185,26 @@ static int do_accept(int fd)
 	return fd;
 }
 
+static void add_zcopy_info(struct msghdr *msg)
+{
+	int i;
+	struct cmsghdr *cm;
+
+	if (!msg->msg_control)
+		error(1, errno, "NULL user arg");
+	cm = (void *)msg->msg_control;
+	/* Although only the address of the array will be written into the
+	 * zc_ckbuf, we assign cmsg_len to CMSG_LEN(sizeof(zc_info)) to specify
+	 * the length of the array.
+	 */
+	cm->cmsg_len = CMSG_LEN(sizeof(zc_info));
+	cm->cmsg_level = SOL_SOCKET;
+	cm->cmsg_type = SCM_ZC_NOTIFICATION;
+	memcpy(CMSG_DATA(cm), &zc_info_ptr, sizeof(zc_info_ptr));
+	for (i = 0; i < SOCK_ZC_INFO_NUM; i++)
+		zc_info[i].zerocopy = INVALID_ZEROCOPY_VAL;
+}
+
 static void add_zcopy_cookie(struct msghdr *msg, uint32_t cookie)
 {
 	struct cmsghdr *cm;
@@ -183,7 +218,7 @@ static void add_zcopy_cookie(struct msghdr *msg, uint32_t cookie)
 	memcpy(CMSG_DATA(cm), &cookie, sizeof(cookie));
 }
 
-static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
+static bool do_sendmsg(int fd, struct msghdr *msg, int do_zerocopy, int domain)
 {
 	int ret, len, i, flags;
 	static uint32_t cookie;
@@ -201,6 +236,15 @@ static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
 			msg->msg_controllen = CMSG_SPACE(sizeof(cookie));
 			msg->msg_control = (struct cmsghdr *)ckbuf;
 			add_zcopy_cookie(msg, ++cookie);
+		} else if (do_zerocopy == ZC_MSGCTL_NOTIFICATION) {
+			memset(&msg->msg_control, 0, sizeof(msg->msg_control));
+			/* Although only the address of the array will be written into the
+			 * zc_ckbuf, msg_controllen must be larger or equal than any cmsg_len
+			 * in it. Otherwise, we will get -EINVAL.
+			 */
+			msg->msg_controllen = CMSG_SPACE(sizeof(zc_info));
+			msg->msg_control = (struct cmsghdr *)zc_ckbuf;
+			add_zcopy_info(msg);
 		}
 	}
 
@@ -219,7 +263,7 @@ static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
 		if (do_zerocopy && ret)
 			expected_completions++;
 	}
-	if (do_zerocopy && domain == PF_RDS) {
+	if (msg->msg_control) {
 		msg->msg_control = NULL;
 		msg->msg_controllen = 0;
 	}
@@ -393,6 +437,42 @@ static bool do_recvmsg_completion(int fd)
 	return ret;
 }
 
+static void do_recv_completions2(void)
+{
+	int i;
+	__u32 hi, lo, range;
+	__u8 zerocopy;
+
+	for (i = 0; zc_info[i].zerocopy != INVALID_ZEROCOPY_VAL; i++) {
+		struct zc_info_elem elem = zc_info[i];
+
+		hi = elem.hi;
+		lo = elem.lo;
+		zerocopy = elem.zerocopy;
+		range = hi - lo + 1;
+
+		if (cfg_verbose && lo != next_completion)
+			fprintf(stderr, "gap: %u..%u does not append to %u\n",
+				lo, hi, next_completion);
+		next_completion = hi + 1;
+
+		if (zerocopied == -1)
+			zerocopied = zerocopy;
+		else if (zerocopied != zerocopy) {
+			fprintf(stderr, "serr: inconsistent\n");
+			zerocopied = zerocopy;
+		}
+
+		completions += range;
+
+		if (cfg_verbose >= 2)
+			fprintf(stderr, "completed: %u (h=%u l=%u)\n",
+				range, hi, lo);
+	}
+
+	sendmsg_counter -= i;
+}
+
 static bool do_recv_completion(int fd, int domain)
 {
 	struct sock_extended_err *serr;
@@ -554,11 +634,15 @@ static void do_tx(int domain, int type, int protocol)
 		else
 			do_sendmsg(fd, &msg, cfg_zerocopy, domain);
 
-		if (cfg_zerocopy && sendmsg_counter >= cfg_notification_limit)
+		if (cfg_zerocopy == ZC_MSGERR_NOTIFICATION &&
+			sendmsg_counter >= cfg_notification_limit)
 			do_recv_completions(fd, domain);
 
+		if (cfg_zerocopy == ZC_MSGCTL_NOTIFICATION)
+			do_recv_completions2();
+
 		while (!do_poll(fd, POLLOUT)) {
-			if (cfg_zerocopy)
+			if (cfg_zerocopy == ZC_MSGERR_NOTIFICATION)
 				do_recv_completions(fd, domain);
 		}
 
@@ -716,7 +800,7 @@ static void parse_opts(int argc, char **argv)
 
 	cfg_payload_len = max_payload_len;
 
-	while ((c = getopt(argc, argv, "46c:C:D:i:l:mp:rs:S:t:vz")) != -1) {
+	while ((c = getopt(argc, argv, "46c:C:D:i:l:mnp:rs:S:t:vz")) != -1) {
 		switch (c) {
 		case '4':
 			if (cfg_family != PF_UNSPEC)
@@ -750,6 +834,9 @@ static void parse_opts(int argc, char **argv)
 		case 'm':
 			cfg_cork_mixed = true;
 			break;
+		case 'n':
+			cfg_zerocopy = ZC_MSGCTL_NOTIFICATION;
+			break;
 		case 'p':
 			cfg_port = strtoul(optarg, NULL, 0);
 			break;
@@ -769,7 +856,7 @@ static void parse_opts(int argc, char **argv)
 			cfg_verbose++;
 			break;
 		case 'z':
-			cfg_zerocopy = true;
+			cfg_zerocopy = ZC_MSGERR_NOTIFICATION;
 			break;
 		}
 	}
@@ -780,6 +867,8 @@ static void parse_opts(int argc, char **argv)
 			error(1, 0, "-D <server addr> required for PF_RDS\n");
 		if (!cfg_rx && !saddr)
 			error(1, 0, "-S <client addr> required for PF_RDS\n");
+		if (cfg_zerocopy == ZC_MSGCTL_NOTIFICATION)
+			error(1, 0, "PF_RDS does not support ZC_MSGCTL_NOTIFICATION");
 	}
 	setup_sockaddr(cfg_family, daddr, &cfg_dst_addr);
 	setup_sockaddr(cfg_family, saddr, &cfg_src_addr);
diff --git a/tools/testing/selftests/net/msg_zerocopy.sh b/tools/testing/selftests/net/msg_zerocopy.sh
index 89c22f5320e0..022a6936d86f 100755
--- a/tools/testing/selftests/net/msg_zerocopy.sh
+++ b/tools/testing/selftests/net/msg_zerocopy.sh
@@ -118,4 +118,5 @@ do_test() {
 
 do_test "${EXTRA_ARGS}"
 do_test "-z ${EXTRA_ARGS}"
+do_test "-n ${EXTRA_ARGS}"
 echo ok
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  2024-05-10 15:58 ` [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control zijianzhang
@ 2024-05-11  5:30   ` kernel test robot
  2024-05-13  0:58   ` Willem de Bruijn
  1 sibling, 0 replies; 10+ messages in thread
From: kernel test robot @ 2024-05-11  5:30 UTC (permalink / raw)
  To: zijianzhang, netdev
  Cc: llvm, oe-kbuild-all, edumazet, willemdebruijn.kernel, cong.wang,
	xiaochun.lu, Zijian Zhang

Hi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/zijianzhang-bytedance-com/selftests-fix-OOM-problem-in-msg_zerocopy-selftest/20240511-000153
base:   net-next/main
patch link:    https://lore.kernel.org/r/20240510155900.1825946-3-zijianzhang%40bytedance.com
patch subject: [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
config: arm-defconfig (https://download.01.org/0day-ci/archive/20240511/202405111306.MOClscNA-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240511/202405111306.MOClscNA-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405111306.MOClscNA-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> net/core/sock.c:2808:5: warning: stack frame size (1608) exceeds limit (1024) in '__sock_cmsg_send' [-Wframe-larger-than]
   int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
       ^
   1 warning generated.


vim +/__sock_cmsg_send +2808 net/core/sock.c

^1da177e4c3f41 Linus Torvalds        2005-04-16  2807  
233baf9a1bc46f xu xin                2022-10-20 @2808  int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
f28ea365cdefc3 Edward Jee            2015-10-08  2809  		     struct sockcm_cookie *sockc)
f28ea365cdefc3 Edward Jee            2015-10-08  2810  {
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2811  	u32 tsflags;
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2812  
f28ea365cdefc3 Edward Jee            2015-10-08  2813  	switch (cmsg->cmsg_type) {
f28ea365cdefc3 Edward Jee            2015-10-08  2814  	case SO_MARK:
91f0d8a4813a9a Jakub Kicinski        2022-01-31  2815  		if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_RAW) &&
91f0d8a4813a9a Jakub Kicinski        2022-01-31  2816  		    !ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
f28ea365cdefc3 Edward Jee            2015-10-08  2817  			return -EPERM;
f28ea365cdefc3 Edward Jee            2015-10-08  2818  		if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
f28ea365cdefc3 Edward Jee            2015-10-08  2819  			return -EINVAL;
f28ea365cdefc3 Edward Jee            2015-10-08  2820  		sockc->mark = *(u32 *)CMSG_DATA(cmsg);
f28ea365cdefc3 Edward Jee            2015-10-08  2821  		break;
7f1bc6e95d7840 Deepa Dinamani        2019-02-02  2822  	case SO_TIMESTAMPING_OLD:
382a32018b74f4 Thomas Lange          2024-01-04  2823  	case SO_TIMESTAMPING_NEW:
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2824  		if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2825  			return -EINVAL;
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2826  
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2827  		tsflags = *(u32 *)CMSG_DATA(cmsg);
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2828  		if (tsflags & ~SOF_TIMESTAMPING_TX_RECORD_MASK)
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2829  			return -EINVAL;
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2830  
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2831  		sockc->tsflags &= ~SOF_TIMESTAMPING_TX_RECORD_MASK;
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2832  		sockc->tsflags |= tsflags;
3dd17e63f5131b Soheil Hassas Yeganeh 2016-04-02  2833  		break;
80b14dee2bea12 Richard Cochran       2018-07-03  2834  	case SCM_TXTIME:
80b14dee2bea12 Richard Cochran       2018-07-03  2835  		if (!sock_flag(sk, SOCK_TXTIME))
80b14dee2bea12 Richard Cochran       2018-07-03  2836  			return -EINVAL;
80b14dee2bea12 Richard Cochran       2018-07-03  2837  		if (cmsg->cmsg_len != CMSG_LEN(sizeof(u64)))
80b14dee2bea12 Richard Cochran       2018-07-03  2838  			return -EINVAL;
80b14dee2bea12 Richard Cochran       2018-07-03  2839  		sockc->transmit_time = get_unaligned((u64 *)CMSG_DATA(cmsg));
80b14dee2bea12 Richard Cochran       2018-07-03  2840  		break;
779f1edec664a7 Soheil Hassas Yeganeh 2016-07-11  2841  	/* SCM_RIGHTS and SCM_CREDENTIALS are semantically in SOL_UNIX. */
779f1edec664a7 Soheil Hassas Yeganeh 2016-07-11  2842  	case SCM_RIGHTS:
779f1edec664a7 Soheil Hassas Yeganeh 2016-07-11  2843  	case SCM_CREDENTIALS:
779f1edec664a7 Soheil Hassas Yeganeh 2016-07-11  2844  		break;
274b6fd4a3053e Zijian Zhang          2024-05-10  2845  	case SCM_ZC_NOTIFICATION: {
274b6fd4a3053e Zijian Zhang          2024-05-10  2846  		int ret, i = 0;
274b6fd4a3053e Zijian Zhang          2024-05-10  2847  		int cmsg_data_len, zc_info_elem_num;
274b6fd4a3053e Zijian Zhang          2024-05-10  2848  		void __user	*usr_addr;
274b6fd4a3053e Zijian Zhang          2024-05-10  2849  		struct zc_info_elem zc_info_kern[SOCK_ZC_INFO_MAX];
274b6fd4a3053e Zijian Zhang          2024-05-10  2850  		unsigned long flags;
274b6fd4a3053e Zijian Zhang          2024-05-10  2851  		struct sk_buff_head *q, local_q;
274b6fd4a3053e Zijian Zhang          2024-05-10  2852  		struct sk_buff *skb, *tmp;
274b6fd4a3053e Zijian Zhang          2024-05-10  2853  		struct sock_exterr_skb *serr;
274b6fd4a3053e Zijian Zhang          2024-05-10  2854  
274b6fd4a3053e Zijian Zhang          2024-05-10  2855  		if (!sock_flag(sk, SOCK_ZEROCOPY) || sk->sk_family == PF_RDS)
274b6fd4a3053e Zijian Zhang          2024-05-10  2856  			return -EINVAL;
274b6fd4a3053e Zijian Zhang          2024-05-10  2857  
274b6fd4a3053e Zijian Zhang          2024-05-10  2858  		cmsg_data_len = cmsg->cmsg_len - sizeof(struct cmsghdr);
274b6fd4a3053e Zijian Zhang          2024-05-10  2859  		if (cmsg_data_len % sizeof(struct zc_info_elem))
274b6fd4a3053e Zijian Zhang          2024-05-10  2860  			return -EINVAL;
274b6fd4a3053e Zijian Zhang          2024-05-10  2861  
274b6fd4a3053e Zijian Zhang          2024-05-10  2862  		zc_info_elem_num = cmsg_data_len / sizeof(struct zc_info_elem);
274b6fd4a3053e Zijian Zhang          2024-05-10  2863  		if (!zc_info_elem_num || zc_info_elem_num > SOCK_ZC_INFO_MAX)
274b6fd4a3053e Zijian Zhang          2024-05-10  2864  			return -EINVAL;
274b6fd4a3053e Zijian Zhang          2024-05-10  2865  
274b6fd4a3053e Zijian Zhang          2024-05-10  2866  		if (in_compat_syscall())
274b6fd4a3053e Zijian Zhang          2024-05-10  2867  			usr_addr = compat_ptr(*(compat_uptr_t *)CMSG_DATA(cmsg));
274b6fd4a3053e Zijian Zhang          2024-05-10  2868  		else
274b6fd4a3053e Zijian Zhang          2024-05-10  2869  			usr_addr = (void __user *)*(void **)CMSG_DATA(cmsg);
274b6fd4a3053e Zijian Zhang          2024-05-10  2870  		if (!access_ok(usr_addr, cmsg_data_len))
274b6fd4a3053e Zijian Zhang          2024-05-10  2871  			return -EFAULT;
274b6fd4a3053e Zijian Zhang          2024-05-10  2872  
274b6fd4a3053e Zijian Zhang          2024-05-10  2873  		q = &sk->sk_error_queue;
274b6fd4a3053e Zijian Zhang          2024-05-10  2874  		skb_queue_head_init(&local_q);
274b6fd4a3053e Zijian Zhang          2024-05-10  2875  		spin_lock_irqsave(&q->lock, flags);
274b6fd4a3053e Zijian Zhang          2024-05-10  2876  		skb = skb_peek(q);
274b6fd4a3053e Zijian Zhang          2024-05-10  2877  		while (skb && i < zc_info_elem_num) {
274b6fd4a3053e Zijian Zhang          2024-05-10  2878  			struct sk_buff *skb_next = skb_peek_next(skb, q);
274b6fd4a3053e Zijian Zhang          2024-05-10  2879  
274b6fd4a3053e Zijian Zhang          2024-05-10  2880  			serr = SKB_EXT_ERR(skb);
274b6fd4a3053e Zijian Zhang          2024-05-10  2881  			if (serr->ee.ee_errno == 0 &&
274b6fd4a3053e Zijian Zhang          2024-05-10  2882  			    serr->ee.ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
274b6fd4a3053e Zijian Zhang          2024-05-10  2883  				zc_info_kern[i].hi = serr->ee.ee_data;
274b6fd4a3053e Zijian Zhang          2024-05-10  2884  				zc_info_kern[i].lo = serr->ee.ee_info;
274b6fd4a3053e Zijian Zhang          2024-05-10  2885  				zc_info_kern[i].zerocopy = !(serr->ee.ee_code
274b6fd4a3053e Zijian Zhang          2024-05-10  2886  								& SO_EE_CODE_ZEROCOPY_COPIED);
274b6fd4a3053e Zijian Zhang          2024-05-10  2887  				__skb_unlink(skb, q);
274b6fd4a3053e Zijian Zhang          2024-05-10  2888  				__skb_queue_tail(&local_q, skb);
274b6fd4a3053e Zijian Zhang          2024-05-10  2889  				i++;
274b6fd4a3053e Zijian Zhang          2024-05-10  2890  			}
274b6fd4a3053e Zijian Zhang          2024-05-10  2891  			skb = skb_next;
274b6fd4a3053e Zijian Zhang          2024-05-10  2892  		}
274b6fd4a3053e Zijian Zhang          2024-05-10  2893  		spin_unlock_irqrestore(&q->lock, flags);
274b6fd4a3053e Zijian Zhang          2024-05-10  2894  
274b6fd4a3053e Zijian Zhang          2024-05-10  2895  		ret = copy_to_user(usr_addr,
274b6fd4a3053e Zijian Zhang          2024-05-10  2896  				   zc_info_kern,
274b6fd4a3053e Zijian Zhang          2024-05-10  2897  					i * sizeof(struct zc_info_elem));
274b6fd4a3053e Zijian Zhang          2024-05-10  2898  
274b6fd4a3053e Zijian Zhang          2024-05-10  2899  		if (unlikely(ret)) {
274b6fd4a3053e Zijian Zhang          2024-05-10  2900  			spin_lock_irqsave(&q->lock, flags);
274b6fd4a3053e Zijian Zhang          2024-05-10  2901  			skb_queue_reverse_walk_safe(&local_q, skb, tmp) {
274b6fd4a3053e Zijian Zhang          2024-05-10  2902  				__skb_unlink(skb, &local_q);
274b6fd4a3053e Zijian Zhang          2024-05-10  2903  				__skb_queue_head(q, skb);
274b6fd4a3053e Zijian Zhang          2024-05-10  2904  			}
274b6fd4a3053e Zijian Zhang          2024-05-10  2905  			spin_unlock_irqrestore(&q->lock, flags);
274b6fd4a3053e Zijian Zhang          2024-05-10  2906  			return -EFAULT;
274b6fd4a3053e Zijian Zhang          2024-05-10  2907  		}
274b6fd4a3053e Zijian Zhang          2024-05-10  2908  
274b6fd4a3053e Zijian Zhang          2024-05-10  2909  		while ((skb = __skb_dequeue(&local_q)))
274b6fd4a3053e Zijian Zhang          2024-05-10  2910  			consume_skb(skb);
274b6fd4a3053e Zijian Zhang          2024-05-10  2911  		break;
274b6fd4a3053e Zijian Zhang          2024-05-10  2912  	}
f28ea365cdefc3 Edward Jee            2015-10-08  2913  	default:
f28ea365cdefc3 Edward Jee            2015-10-08  2914  		return -EINVAL;
f28ea365cdefc3 Edward Jee            2015-10-08  2915  	}
39771b127b4123 Willem de Bruijn      2016-04-02  2916  	return 0;
39771b127b4123 Willem de Bruijn      2016-04-02  2917  }
39771b127b4123 Willem de Bruijn      2016-04-02  2918  EXPORT_SYMBOL(__sock_cmsg_send);
39771b127b4123 Willem de Bruijn      2016-04-02  2919  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest
  2024-05-10 15:58 ` [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest zijianzhang
@ 2024-05-13  0:47   ` Willem de Bruijn
  0 siblings, 0 replies; 10+ messages in thread
From: Willem de Bruijn @ 2024-05-13  0:47 UTC (permalink / raw)
  To: zijianzhang, netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

zijianzhang@ wrote:
> From: Zijian Zhang <zijianzhang@bytedance.com>
> 
> In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg
> on a socket with MSG_ZEROCOPY flag, and it will recv the notifications
> until the socket is not writable. Typically, it will start the receiving
> process after around 30+ sendmsgs. However, because of the
> commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale")
> the sender is always writable and does not get any chance to run recv
> notifications. The selftest always exits with OUT_OF_MEMORY because the
> memory used by opt_skb exceeds the core.sysctl_optmem_max.
> 
> According to our experiments, this problem can be mitigated by open the
> DEBUG_LOCKDEP configuration for the kernel. But it will makes the
> notifications disordered even in good commits before
> commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale").
> 
> We introduce "cfg_notification_limit" to force sender to receive
> notifications after some number of sendmsgs. And, notifications may not
> come in order, because of the reason we present above. We have order
> checking code managed by cfg_verbose.
> 
> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
> Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
> ---
>  tools/testing/selftests/net/msg_zerocopy.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/net/msg_zerocopy.c b/tools/testing/selftests/net/msg_zerocopy.c
> index bdc03a2097e8..ba6c257f689c 100644
> --- a/tools/testing/selftests/net/msg_zerocopy.c
> +++ b/tools/testing/selftests/net/msg_zerocopy.c
> @@ -85,6 +85,7 @@ static bool cfg_rx;
>  static int  cfg_runtime_ms	= 4200;
>  static int  cfg_verbose;
>  static int  cfg_waittime_ms	= 500;
> +static int  cfg_notification_limit = 32;
>  static bool cfg_zerocopy;
>  
>  static socklen_t cfg_alen;
> @@ -95,6 +96,8 @@ static char payload[IP_MAXPACKET];
>  static long packets, bytes, completions, expected_completions;
>  static int  zerocopied = -1;
>  static uint32_t next_completion;
> +/* The number of sendmsgs which have not received notified yet */
> +static uint32_t sendmsg_counter;

minor: comment typo. Consider a more self documenting variable and
drop the comment

static int sends_since_notify;

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  2024-05-10 15:58 ` [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control zijianzhang
  2024-05-11  5:30   ` kernel test robot
@ 2024-05-13  0:58   ` Willem de Bruijn
  2024-05-13 19:47     ` [External] " Zijian Zhang
  1 sibling, 1 reply; 10+ messages in thread
From: Willem de Bruijn @ 2024-05-13  0:58 UTC (permalink / raw)
  To: zijianzhang, netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

zijianzhang@ wrote:
> From: Zijian Zhang <zijianzhang@bytedance.com>
> 
> The MSG_ZEROCOPY flag enables copy avoidance for socket send calls.
> However, zerocopy is not a free lunch. Apart from the management of user
> pages, the combination of poll + recvmsg to receive notifications incurs
> unignorable overhead in the applications. The overhead of such sometimes
> might be more than the CPU savings from zerocopy. We try to solve this
> problem with a new notification mechanism based on msgcontrol.
> This new mechanism aims to reduce the overhead associated with receiving
> notifications by embedding them directly into user arguments passed with
> each sendmsg control message. By doing so, we can significantly reduce
> the complexity and overhead for managing notifications. In an ideal
> pattern, the user will keep calling sendmsg with SCM_ZC_NOTIFICATION
> msg_control, and the notification will be delivered as soon as possible.
> 
> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
> Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>

> +#include <linux/types.h>
> +
>  /*
>   * Desired design of maximum size and alignment (see RFC2553)
>   */
> @@ -35,4 +37,12 @@ struct __kernel_sockaddr_storage {
>  #define SOCK_TXREHASH_DISABLED	0
>  #define SOCK_TXREHASH_ENABLED	1
>  
> +#define SOCK_ZC_INFO_MAX 128
> +
> +struct zc_info_elem {
> +	__u32 lo;
> +	__u32 hi;
> +	__u8 zerocopy;
> +};
> +
>  #endif /* _UAPI_LINUX_SOCKET_H */
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 8d6e638b5426..15da609be026 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2842,6 +2842,74 @@ int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
>  	case SCM_RIGHTS:
>  	case SCM_CREDENTIALS:
>  		break;
> +	case SCM_ZC_NOTIFICATION: {
> +		int ret, i = 0;
> +		int cmsg_data_len, zc_info_elem_num;
> +		void __user	*usr_addr;
> +		struct zc_info_elem zc_info_kern[SOCK_ZC_INFO_MAX];
> +		unsigned long flags;
> +		struct sk_buff_head *q, local_q;
> +		struct sk_buff *skb, *tmp;
> +		struct sock_exterr_skb *serr;

minor: reverse xmas tree

> +
> +		if (!sock_flag(sk, SOCK_ZEROCOPY) || sk->sk_family == PF_RDS)
> +			return -EINVAL;

Is this mechanism supported for PF_RDS?
The next patch fails on PF_RDS + '-n'

> +
> +		cmsg_data_len = cmsg->cmsg_len - sizeof(struct cmsghdr);
> +		if (cmsg_data_len % sizeof(struct zc_info_elem))
> +			return -EINVAL;
> +
> +		zc_info_elem_num = cmsg_data_len / sizeof(struct zc_info_elem);
> +		if (!zc_info_elem_num || zc_info_elem_num > SOCK_ZC_INFO_MAX)
> +			return -EINVAL;
> +
> +		if (in_compat_syscall())
> +			usr_addr = compat_ptr(*(compat_uptr_t *)CMSG_DATA(cmsg));
> +		else
> +			usr_addr = (void __user *)*(void **)CMSG_DATA(cmsg);

The main design issue with this series is this indirection, rather
than passing the array of notifications as cmsg.

This trick circumvents having to deal with compat issues and having to
figure out copy_to_user in ____sys_sendmsg (as msg_control is an
in-kernel copy).

This is quite hacky, from an API design PoV.

As is passing a pointer, but expecting msg_controllen to hold the
length not of the pointer, but of the pointed to user buffer.

I had also hoped for more significant savings. Especially with the
higher syscall overhead due to meltdown and spectre mitigations vs
when MSG_ZEROCOPY was introduced and I last tried this optimization.

> +		if (!access_ok(usr_addr, cmsg_data_len))
> +			return -EFAULT;
> +
> +		q = &sk->sk_error_queue;
> +		skb_queue_head_init(&local_q);
> +		spin_lock_irqsave(&q->lock, flags);
> +		skb = skb_peek(q);
> +		while (skb && i < zc_info_elem_num) {
> +			struct sk_buff *skb_next = skb_peek_next(skb, q);
> +
> +			serr = SKB_EXT_ERR(skb);
> +			if (serr->ee.ee_errno == 0 &&
> +			    serr->ee.ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
> +				zc_info_kern[i].hi = serr->ee.ee_data;
> +				zc_info_kern[i].lo = serr->ee.ee_info;
> +				zc_info_kern[i].zerocopy = !(serr->ee.ee_code
> +								& SO_EE_CODE_ZEROCOPY_COPIED);
> +				__skb_unlink(skb, q);
> +				__skb_queue_tail(&local_q, skb);
> +				i++;
> +			}
> +			skb = skb_next;
> +		}
> +		spin_unlock_irqrestore(&q->lock, flags);
> +
> +		ret = copy_to_user(usr_addr,
> +				   zc_info_kern,
> +					i * sizeof(struct zc_info_elem));
> +
> +		if (unlikely(ret)) {
> +			spin_lock_irqsave(&q->lock, flags);
> +			skb_queue_reverse_walk_safe(&local_q, skb, tmp) {
> +				__skb_unlink(skb, &local_q);
> +				__skb_queue_head(q, skb);
> +			}

Can just list_splice_init?

> +			spin_unlock_irqrestore(&q->lock, flags);
> +			return -EFAULT;
> +		}
> +
> +		while ((skb = __skb_dequeue(&local_q)))
> +			consume_skb(skb);
> +		break;
> +	}
>  	default:
>  		return -EINVAL;
>  	}
> -- 
> 2.20.1
> 



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test
  2024-05-10 15:59 ` [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test zijianzhang
@ 2024-05-13  1:02   ` Willem de Bruijn
  0 siblings, 0 replies; 10+ messages in thread
From: Willem de Bruijn @ 2024-05-13  1:02 UTC (permalink / raw)
  To: zijianzhang, netdev
  Cc: edumazet, willemdebruijn.kernel, cong.wang, xiaochun.lu,
	Zijian Zhang

zijianzhang@ wrote:
> From: Zijian Zhang <zijianzhang@bytedance.com>
> 
> We update selftests/net/msg_zerocopy.c to accommodate the new mechanism.
> 
> Test result from selftests/net/msg_zerocopy.c,
> cfg_notification_limit = 1, in this case MSG_ZEROCOPY approximately
> aligns with the semantics of MSG_ZEROCOPY_UARG. In this case, the new
> flag has around 13% cpu savings in TCP and 18% cpu savings in UDP.
> +---------------------+---------+---------+---------+---------+
> | Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
> +---------------------+---------+---------+---------+---------+
> | ZCopy (MB)          | 5147    | 4885    | 7489    | 7854    |
> +---------------------+---------+---------+---------+---------+
> | New ZCopy (MB)      | 5859    | 5505    | 9053    | 9236    |
> +---------------------+---------+---------+---------+---------+
> | New ZCopy / ZCopy   | 113.83% | 112.69% | 120.88% | 117.59% |
> +---------------------+---------+---------+---------+---------+
> 
> cfg_notification_limit = 32, it means less poll + recvmsg overhead,
> the new mechanism performs 8% better in TCP. For UDP, no obvious
> performance gain is observed and sometimes may lead to degradation.
> Thus, if users don't need to retrieve the notification ASAP in UDP,
> the original mechanism is preferred.
> +---------------------+---------+---------+---------+---------+
> | Test Type / Protocol| TCP v4  | TCP v6  | UDP v4  | UDP v6  |
> +---------------------+---------+---------+---------+---------+
> | ZCopy (MB)          | 6272    | 6138    | 12138   | 10055   |
> +---------------------+---------+---------+---------+---------+
> | New ZCopy (MB)      | 6774    | 6620    | 11504   | 10355   |
> +---------------------+---------+---------+---------+---------+
> | New ZCopy / ZCopy   | 108.00% | 107.85% | 94.78%  | 102.98% |
> +---------------------+---------+---------+---------+---------+
> 
> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
> Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
> ---
>  tools/testing/selftests/net/msg_zerocopy.c  | 103 ++++++++++++++++++--
>  tools/testing/selftests/net/msg_zerocopy.sh |   1 +
>  2 files changed, 97 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/testing/selftests/net/msg_zerocopy.c b/tools/testing/selftests/net/msg_zerocopy.c
> index ba6c257f689c..48750a7a162c 100644
> --- a/tools/testing/selftests/net/msg_zerocopy.c
> +++ b/tools/testing/selftests/net/msg_zerocopy.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /* Evaluate MSG_ZEROCOPY
>   *
>   * Send traffic between two processes over one of the supported
> @@ -66,6 +67,10 @@
>  #define SO_ZEROCOPY	60
>  #endif
>  
> +#ifndef SCM_ZC_NOTIFICATION
> +#define SCM_ZC_NOTIFICATION	78
> +#endif
> +
>  #ifndef SO_EE_CODE_ZEROCOPY_COPIED
>  #define SO_EE_CODE_ZEROCOPY_COPIED	1
>  #endif
> @@ -74,6 +79,13 @@
>  #define MSG_ZEROCOPY	0x4000000
>  #endif
>  
> +#define ZC_MSGERR_NOTIFICATION 1
> +#define ZC_MSGCTL_NOTIFICATION 2

Please define an enum

And consider less truncated, more descriptive, names. E.g.,

   MSG_ZEROCOPY_NOTIFY_ERRQUEUE
   MSG_ZEROCOPY_NOTIFY_SENDMSG

> +
> +#define SOCK_ZC_INFO_NUM 8
> +
> +#define INVALID_ZEROCOPY_VAL 2
> +
>  static int  cfg_cork;
>  static bool cfg_cork_mixed;
>  static int  cfg_cpu		= -1;		/* default: pin to last cpu */
> @@ -86,13 +98,16 @@ static int  cfg_runtime_ms	= 4200;
>  static int  cfg_verbose;
>  static int  cfg_waittime_ms	= 500;
>  static int  cfg_notification_limit = 32;
> -static bool cfg_zerocopy;
> +static int  cfg_zerocopy;           /* Either 1 or 2, mode for SO_ZEROCOPY */
>  
>  static socklen_t cfg_alen;
>  static struct sockaddr_storage cfg_dst_addr;
>  static struct sockaddr_storage cfg_src_addr;
>  
>  static char payload[IP_MAXPACKET];
> +static struct zc_info_elem zc_info[SOCK_ZC_INFO_NUM];
> +static char zc_ckbuf[CMSG_SPACE(sizeof(void *))];
> +static struct zc_info_elem *zc_info_ptr = zc_info;
>  static long packets, bytes, completions, expected_completions;
>  static int  zerocopied = -1;
>  static uint32_t next_completion;
> @@ -170,6 +185,26 @@ static int do_accept(int fd)
>  	return fd;
>  }
>  
> +static void add_zcopy_info(struct msghdr *msg)
> +{
> +	int i;
> +	struct cmsghdr *cm;
> +
> +	if (!msg->msg_control)
> +		error(1, errno, "NULL user arg");
> +	cm = (void *)msg->msg_control;
> +	/* Although only the address of the array will be written into the
> +	 * zc_ckbuf, we assign cmsg_len to CMSG_LEN(sizeof(zc_info)) to specify
> +	 * the length of the array.
> +	 */
> +	cm->cmsg_len = CMSG_LEN(sizeof(zc_info));
> +	cm->cmsg_level = SOL_SOCKET;
> +	cm->cmsg_type = SCM_ZC_NOTIFICATION;
> +	memcpy(CMSG_DATA(cm), &zc_info_ptr, sizeof(zc_info_ptr));
> +	for (i = 0; i < SOCK_ZC_INFO_NUM; i++)
> +		zc_info[i].zerocopy = INVALID_ZEROCOPY_VAL;
> +}
> +
>  static void add_zcopy_cookie(struct msghdr *msg, uint32_t cookie)
>  {
>  	struct cmsghdr *cm;
> @@ -183,7 +218,7 @@ static void add_zcopy_cookie(struct msghdr *msg, uint32_t cookie)
>  	memcpy(CMSG_DATA(cm), &cookie, sizeof(cookie));
>  }
>  
> -static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
> +static bool do_sendmsg(int fd, struct msghdr *msg, int do_zerocopy, int domain)
>  {
>  	int ret, len, i, flags;
>  	static uint32_t cookie;
> @@ -201,6 +236,15 @@ static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
>  			msg->msg_controllen = CMSG_SPACE(sizeof(cookie));
>  			msg->msg_control = (struct cmsghdr *)ckbuf;
>  			add_zcopy_cookie(msg, ++cookie);
> +		} else if (do_zerocopy == ZC_MSGCTL_NOTIFICATION) {
> +			memset(&msg->msg_control, 0, sizeof(msg->msg_control));
> +			/* Although only the address of the array will be written into the
> +			 * zc_ckbuf, msg_controllen must be larger or equal than any cmsg_len
> +			 * in it. Otherwise, we will get -EINVAL.
> +			 */
> +			msg->msg_controllen = CMSG_SPACE(sizeof(zc_info));
> +			msg->msg_control = (struct cmsghdr *)zc_ckbuf;
> +			add_zcopy_info(msg);
>  		}
>  	}
>  
> @@ -219,7 +263,7 @@ static bool do_sendmsg(int fd, struct msghdr *msg, bool do_zerocopy, int domain)
>  		if (do_zerocopy && ret)
>  			expected_completions++;
>  	}
> -	if (do_zerocopy && domain == PF_RDS) {
> +	if (msg->msg_control) {
>  		msg->msg_control = NULL;
>  		msg->msg_controllen = 0;
>  	}
> @@ -393,6 +437,42 @@ static bool do_recvmsg_completion(int fd)
>  	return ret;
>  }
>  
> +static void do_recv_completions2(void)
> +{
> +	int i;
> +	__u32 hi, lo, range;
> +	__u8 zerocopy;
> +
> +	for (i = 0; zc_info[i].zerocopy != INVALID_ZEROCOPY_VAL; i++) {
> +		struct zc_info_elem elem = zc_info[i];
> +
> +		hi = elem.hi;
> +		lo = elem.lo;
> +		zerocopy = elem.zerocopy;
> +		range = hi - lo + 1;
> +
> +		if (cfg_verbose && lo != next_completion)
> +			fprintf(stderr, "gap: %u..%u does not append to %u\n",
> +				lo, hi, next_completion);
> +		next_completion = hi + 1;
> +
> +		if (zerocopied == -1)
> +			zerocopied = zerocopy;
> +		else if (zerocopied != zerocopy) {
> +			fprintf(stderr, "serr: inconsistent\n");
> +			zerocopied = zerocopy;
> +		}
> +
> +		completions += range;
> +
> +		if (cfg_verbose >= 2)
> +			fprintf(stderr, "completed: %u (h=%u l=%u)\n",
> +				range, hi, lo);
> +	}
> +
> +	sendmsg_counter -= i;
> +}
> +
>  static bool do_recv_completion(int fd, int domain)
>  {
>  	struct sock_extended_err *serr;
> @@ -554,11 +634,15 @@ static void do_tx(int domain, int type, int protocol)
>  		else
>  			do_sendmsg(fd, &msg, cfg_zerocopy, domain);
>  
> -		if (cfg_zerocopy && sendmsg_counter >= cfg_notification_limit)
> +		if (cfg_zerocopy == ZC_MSGERR_NOTIFICATION &&
> +			sendmsg_counter >= cfg_notification_limit)
>  			do_recv_completions(fd, domain);
>  
> +		if (cfg_zerocopy == ZC_MSGCTL_NOTIFICATION)
> +			do_recv_completions2();
> +
>  		while (!do_poll(fd, POLLOUT)) {
> -			if (cfg_zerocopy)
> +			if (cfg_zerocopy == ZC_MSGERR_NOTIFICATION)
>  				do_recv_completions(fd, domain);
>  		}
>  
> @@ -716,7 +800,7 @@ static void parse_opts(int argc, char **argv)
>  
>  	cfg_payload_len = max_payload_len;
>  
> -	while ((c = getopt(argc, argv, "46c:C:D:i:l:mp:rs:S:t:vz")) != -1) {
> +	while ((c = getopt(argc, argv, "46c:C:D:i:l:mnp:rs:S:t:vz")) != -1) {
>  		switch (c) {
>  		case '4':
>  			if (cfg_family != PF_UNSPEC)
> @@ -750,6 +834,9 @@ static void parse_opts(int argc, char **argv)
>  		case 'm':
>  			cfg_cork_mixed = true;
>  			break;
> +		case 'n':
> +			cfg_zerocopy = ZC_MSGCTL_NOTIFICATION;
> +			break;
>  		case 'p':
>  			cfg_port = strtoul(optarg, NULL, 0);
>  			break;
> @@ -769,7 +856,7 @@ static void parse_opts(int argc, char **argv)
>  			cfg_verbose++;
>  			break;
>  		case 'z':
> -			cfg_zerocopy = true;
> +			cfg_zerocopy = ZC_MSGERR_NOTIFICATION;
>  			break;
>  		}
>  	}
> @@ -780,6 +867,8 @@ static void parse_opts(int argc, char **argv)
>  			error(1, 0, "-D <server addr> required for PF_RDS\n");
>  		if (!cfg_rx && !saddr)
>  			error(1, 0, "-S <client addr> required for PF_RDS\n");
> +		if (cfg_zerocopy == ZC_MSGCTL_NOTIFICATION)
> +			error(1, 0, "PF_RDS does not support ZC_MSGCTL_NOTIFICATION");
>  	}
>  	setup_sockaddr(cfg_family, daddr, &cfg_dst_addr);
>  	setup_sockaddr(cfg_family, saddr, &cfg_src_addr);
> diff --git a/tools/testing/selftests/net/msg_zerocopy.sh b/tools/testing/selftests/net/msg_zerocopy.sh
> index 89c22f5320e0..022a6936d86f 100755
> --- a/tools/testing/selftests/net/msg_zerocopy.sh
> +++ b/tools/testing/selftests/net/msg_zerocopy.sh
> @@ -118,4 +118,5 @@ do_test() {
>  
>  do_test "${EXTRA_ARGS}"
>  do_test "-z ${EXTRA_ARGS}"
> +do_test "-n ${EXTRA_ARGS}"
>  echo ok
> -- 
> 2.20.1
> 



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [External] Re: [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  2024-05-13  0:58   ` Willem de Bruijn
@ 2024-05-13 19:47     ` Zijian Zhang
  2024-05-13 20:22       ` Zijian Zhang
  0 siblings, 1 reply; 10+ messages in thread
From: Zijian Zhang @ 2024-05-13 19:47 UTC (permalink / raw)
  To: Willem de Bruijn, netdev; +Cc: edumazet, cong.wang, xiaochun.lu

On 5/12/24 5:58 PM, Willem de Bruijn wrote:
> zijianzhang@ wrote:
>> From: Zijian Zhang <zijianzhang@bytedance.com>
>>
>> The MSG_ZEROCOPY flag enables copy avoidance for socket send calls.
>> However, zerocopy is not a free lunch. Apart from the management of user
>> pages, the combination of poll + recvmsg to receive notifications incurs
>> unignorable overhead in the applications. The overhead of such sometimes
>> might be more than the CPU savings from zerocopy. We try to solve this
>> problem with a new notification mechanism based on msgcontrol.
>> This new mechanism aims to reduce the overhead associated with receiving
>> notifications by embedding them directly into user arguments passed with
>> each sendmsg control message. By doing so, we can significantly reduce
>> the complexity and overhead for managing notifications. In an ideal
>> pattern, the user will keep calling sendmsg with SCM_ZC_NOTIFICATION
>> msg_control, and the notification will be delivered as soon as possible.
>>
>> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
>> Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
> 
>> +#include <linux/types.h>
>> +
>>   /*
>>    * Desired design of maximum size and alignment (see RFC2553)
>>    */
>> @@ -35,4 +37,12 @@ struct __kernel_sockaddr_storage {
>>   #define SOCK_TXREHASH_DISABLED	0
>>   #define SOCK_TXREHASH_ENABLED	1
>>   
>> +#define SOCK_ZC_INFO_MAX 128
>> +
>> +struct zc_info_elem {
>> +	__u32 lo;
>> +	__u32 hi;
>> +	__u8 zerocopy;
>> +};
>> +
>>   #endif /* _UAPI_LINUX_SOCKET_H */
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index 8d6e638b5426..15da609be026 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
>> @@ -2842,6 +2842,74 @@ int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
>>   	case SCM_RIGHTS:
>>   	case SCM_CREDENTIALS:
>>   		break;
>> +	case SCM_ZC_NOTIFICATION: {
>> +		int ret, i = 0;
>> +		int cmsg_data_len, zc_info_elem_num;
>> +		void __user	*usr_addr;
>> +		struct zc_info_elem zc_info_kern[SOCK_ZC_INFO_MAX];
>> +		unsigned long flags;
>> +		struct sk_buff_head *q, local_q;
>> +		struct sk_buff *skb, *tmp;
>> +		struct sock_exterr_skb *serr;
> 
> minor: reverse xmas tree
> 

Ack.

>> +
>> +		if (!sock_flag(sk, SOCK_ZEROCOPY) || sk->sk_family == PF_RDS)
>> +			return -EINVAL;
> 
> Is this mechanism supported for PF_RDS?
> The next patch fails on PF_RDS + '-n'
> 

Nice catch! This mechanism does not support PF_RDS, I will update the
selftest code.

>> +
>> +		cmsg_data_len = cmsg->cmsg_len - sizeof(struct cmsghdr);
>> +		if (cmsg_data_len % sizeof(struct zc_info_elem))
>> +			return -EINVAL;
>> +
>> +		zc_info_elem_num = cmsg_data_len / sizeof(struct zc_info_elem);
>> +		if (!zc_info_elem_num || zc_info_elem_num > SOCK_ZC_INFO_MAX)
>> +			return -EINVAL;
>> +
>> +		if (in_compat_syscall())
>> +			usr_addr = compat_ptr(*(compat_uptr_t *)CMSG_DATA(cmsg));
>> +		else
>> +			usr_addr = (void __user *)*(void **)CMSG_DATA(cmsg);
> 
> The main design issue with this series is this indirection, rather
> than passing the array of notifications as cmsg.
> 
> This trick circumvents having to deal with compat issues and having to
> figure out copy_to_user in ____sys_sendmsg (as msg_control is an
> in-kernel copy).
> 
> This is quite hacky, from an API design PoV.
> 
> As is passing a pointer, but expecting msg_controllen to hold the
> length not of the pointer, but of the pointed to user buffer.
> 
> I had also hoped for more significant savings. Especially with the
> higher syscall overhead due to meltdown and spectre mitigations vs
> when MSG_ZEROCOPY was introduced and I last tried this optimization.
>
Thanks for the summary, totally agree! It's a hard choice to design the
API like this.

>> +		if (!access_ok(usr_addr, cmsg_data_len))
>> +			return -EFAULT;
>> +
>> +		q = &sk->sk_error_queue;
>> +		skb_queue_head_init(&local_q);
>> +		spin_lock_irqsave(&q->lock, flags);
>> +		skb = skb_peek(q);
>> +		while (skb && i < zc_info_elem_num) {
>> +			struct sk_buff *skb_next = skb_peek_next(skb, q);
>> +
>> +			serr = SKB_EXT_ERR(skb);
>> +			if (serr->ee.ee_errno == 0 &&
>> +			    serr->ee.ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
>> +				zc_info_kern[i].hi = serr->ee.ee_data;
>> +				zc_info_kern[i].lo = serr->ee.ee_info;
>> +				zc_info_kern[i].zerocopy = !(serr->ee.ee_code
>> +								& SO_EE_CODE_ZEROCOPY_COPIED);
>> +				__skb_unlink(skb, q);
>> +				__skb_queue_tail(&local_q, skb);
>> +				i++;
>> +			}
>> +			skb = skb_next;
>> +		}
>> +		spin_unlock_irqrestore(&q->lock, flags);
>> +
>> +		ret = copy_to_user(usr_addr,
>> +				   zc_info_kern,
>> +					i * sizeof(struct zc_info_elem));
>> +
>> +		if (unlikely(ret)) {
>> +			spin_lock_irqsave(&q->lock, flags);
>> +			skb_queue_reverse_walk_safe(&local_q, skb, tmp) {
>> +				__skb_unlink(skb, &local_q);
>> +				__skb_queue_head(q, skb);
>> +			}
> 
> Can just list_splice_init?
> 

Ack.

>> +			spin_unlock_irqrestore(&q->lock, flags);
>> +			return -EFAULT;
>> +		}
>> +
>> +		while ((skb = __skb_dequeue(&local_q)))
>> +			consume_skb(skb);
>> +		break;
>> +	}
>>   	default:
>>   		return -EINVAL;
>>   	}
>> -- 
>> 2.20.1
>>
> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [External] Re: [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control
  2024-05-13 19:47     ` [External] " Zijian Zhang
@ 2024-05-13 20:22       ` Zijian Zhang
  0 siblings, 0 replies; 10+ messages in thread
From: Zijian Zhang @ 2024-05-13 20:22 UTC (permalink / raw)
  To: Willem de Bruijn, netdev; +Cc: edumazet, cong.wang, xiaochun.lu

On 5/13/24 12:47 PM, Zijian Zhang wrote:
> On 5/12/24 5:58 PM, Willem de Bruijn wrote:
>> zijianzhang@ wrote:
>>> From: Zijian Zhang <zijianzhang@bytedance.com>
>>>
>>> The MSG_ZEROCOPY flag enables copy avoidance for socket send calls.
>>> However, zerocopy is not a free lunch. Apart from the management of user
>>> pages, the combination of poll + recvmsg to receive notifications incurs
>>> unignorable overhead in the applications. The overhead of such sometimes
>>> might be more than the CPU savings from zerocopy. We try to solve this
>>> problem with a new notification mechanism based on msgcontrol.
>>> This new mechanism aims to reduce the overhead associated with receiving
>>> notifications by embedding them directly into user arguments passed with
>>> each sendmsg control message. By doing so, we can significantly reduce
>>> the complexity and overhead for managing notifications. In an ideal
>>> pattern, the user will keep calling sendmsg with SCM_ZC_NOTIFICATION
>>> msg_control, and the notification will be delivered as soon as possible.
>>>
>>> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
>>> Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
>>
>>> +#include <linux/types.h>
>>> +
>>>   /*
>>>    * Desired design of maximum size and alignment (see RFC2553)
>>>    */
>>> @@ -35,4 +37,12 @@ struct __kernel_sockaddr_storage {
>>>   #define SOCK_TXREHASH_DISABLED    0
>>>   #define SOCK_TXREHASH_ENABLED    1
>>> +#define SOCK_ZC_INFO_MAX 128
>>> +
>>> +struct zc_info_elem {
>>> +    __u32 lo;
>>> +    __u32 hi;
>>> +    __u8 zerocopy;
>>> +};
>>> +
>>>   #endif /* _UAPI_LINUX_SOCKET_H */
>>> diff --git a/net/core/sock.c b/net/core/sock.c
>>> index 8d6e638b5426..15da609be026 100644
>>> --- a/net/core/sock.c
>>> +++ b/net/core/sock.c
>>> @@ -2842,6 +2842,74 @@ int __sock_cmsg_send(struct sock *sk, struct 
>>> cmsghdr *cmsg,
>>>       case SCM_RIGHTS:
>>>       case SCM_CREDENTIALS:
>>>           break;
>>> +    case SCM_ZC_NOTIFICATION: {
>>> +        int ret, i = 0;
>>> +        int cmsg_data_len, zc_info_elem_num;
>>> +        void __user    *usr_addr;
>>> +        struct zc_info_elem zc_info_kern[SOCK_ZC_INFO_MAX];
>>> +        unsigned long flags;
>>> +        struct sk_buff_head *q, local_q;
>>> +        struct sk_buff *skb, *tmp;
>>> +        struct sock_exterr_skb *serr;
>>
>> minor: reverse xmas tree
>>
> 
> Ack.
> 
>>> +
>>> +        if (!sock_flag(sk, SOCK_ZEROCOPY) || sk->sk_family == PF_RDS)
>>> +            return -EINVAL;
>>
>> Is this mechanism supported for PF_RDS?
>> The next patch fails on PF_RDS + '-n'
>>
> 
> Nice catch! This mechanism does not support PF_RDS, I will update the
> selftest code.
> 

PF_RDS does not use MSGERR queue to store the info, thus it is not
supported by this patch. I will leave it as "unsupported" in the 
"selftest -n" now.

If possible, I may leave the support for PF_RDS in another patch set in
the future.

>>> +
>>> +        cmsg_data_len = cmsg->cmsg_len - sizeof(struct cmsghdr);
>>> +        if (cmsg_data_len % sizeof(struct zc_info_elem))
>>> +            return -EINVAL;
>>> +
>>> +        zc_info_elem_num = cmsg_data_len / sizeof(struct zc_info_elem);
>>> +        if (!zc_info_elem_num || zc_info_elem_num > SOCK_ZC_INFO_MAX)
>>> +            return -EINVAL;
>>> +
>>> +        if (in_compat_syscall())
>>> +            usr_addr = compat_ptr(*(compat_uptr_t *)CMSG_DATA(cmsg));
>>> +        else
>>> +            usr_addr = (void __user *)*(void **)CMSG_DATA(cmsg);
>>
>> The main design issue with this series is this indirection, rather
>> than passing the array of notifications as cmsg.
>>
>> This trick circumvents having to deal with compat issues and having to
>> figure out copy_to_user in ____sys_sendmsg (as msg_control is an
>> in-kernel copy).
>>
>> This is quite hacky, from an API design PoV.
>>
>> As is passing a pointer, but expecting msg_controllen to hold the
>> length not of the pointer, but of the pointed to user buffer.
>>
>> I had also hoped for more significant savings. Especially with the
>> higher syscall overhead due to meltdown and spectre mitigations vs
>> when MSG_ZEROCOPY was introduced and I last tried this optimization.
>>
> Thanks for the summary, totally agree! It's a hard choice to design the
> API like this.
> 
>>> +        if (!access_ok(usr_addr, cmsg_data_len))
>>> +            return -EFAULT;
>>> +
>>> +        q = &sk->sk_error_queue;
>>> +        skb_queue_head_init(&local_q);
>>> +        spin_lock_irqsave(&q->lock, flags);
>>> +        skb = skb_peek(q);
>>> +        while (skb && i < zc_info_elem_num) {
>>> +            struct sk_buff *skb_next = skb_peek_next(skb, q);
>>> +
>>> +            serr = SKB_EXT_ERR(skb);
>>> +            if (serr->ee.ee_errno == 0 &&
>>> +                serr->ee.ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
>>> +                zc_info_kern[i].hi = serr->ee.ee_data;
>>> +                zc_info_kern[i].lo = serr->ee.ee_info;
>>> +                zc_info_kern[i].zerocopy = !(serr->ee.ee_code
>>> +                                & SO_EE_CODE_ZEROCOPY_COPIED);
>>> +                __skb_unlink(skb, q);
>>> +                __skb_queue_tail(&local_q, skb);
>>> +                i++;
>>> +            }
>>> +            skb = skb_next;
>>> +        }
>>> +        spin_unlock_irqrestore(&q->lock, flags);
>>> +
>>> +        ret = copy_to_user(usr_addr,
>>> +                   zc_info_kern,
>>> +                    i * sizeof(struct zc_info_elem));
>>> +
>>> +        if (unlikely(ret)) {
>>> +            spin_lock_irqsave(&q->lock, flags);
>>> +            skb_queue_reverse_walk_safe(&local_q, skb, tmp) {
>>> +                __skb_unlink(skb, &local_q);
>>> +                __skb_queue_head(q, skb);
>>> +            }
>>
>> Can just list_splice_init?
>>
> 
> Ack.
> 
>>> +            spin_unlock_irqrestore(&q->lock, flags);
>>> +            return -EFAULT;
>>> +        }
>>> +
>>> +        while ((skb = __skb_dequeue(&local_q)))
>>> +            consume_skb(skb);
>>> +        break;
>>> +    }
>>>       default:
>>>           return -EINVAL;
>>>       }
>>> -- 
>>> 2.20.1
>>>
>>
>>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-05-13 20:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-10 15:58 [PATCH net-next v3 0/3] net: A lightweight zero-copy notification zijianzhang
2024-05-10 15:58 ` [PATCH net-next v3 1/3] selftests: fix OOM problem in msg_zerocopy selftest zijianzhang
2024-05-13  0:47   ` Willem de Bruijn
2024-05-10 15:58 ` [PATCH net-next v3 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control zijianzhang
2024-05-11  5:30   ` kernel test robot
2024-05-13  0:58   ` Willem de Bruijn
2024-05-13 19:47     ` [External] " Zijian Zhang
2024-05-13 20:22       ` Zijian Zhang
2024-05-10 15:59 ` [PATCH net-next v3 3/3] selftests: add MSG_ZEROCOPY msg_control notification test zijianzhang
2024-05-13  1:02   ` Willem de Bruijn

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