Re: [RFC PATCH v5 13/17] vsock: enable setting SO_ZEROCOPY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 01, 2023 at 09:39:43AM +0300, Arseniy Krasnov wrote:
For AF_VSOCK, zerocopy tx mode depends on transport, so this option must
be set in AF_VSOCK implementation where transport is accessible (if
transport is not set during setting SO_ZEROCOPY: for example socket is
not connected, then SO_ZEROCOPY will be enabled, but once transport will
be assigned, support of this type of transmission will be checked).

To handle SO_ZEROCOPY, AF_VSOCK implementation uses SOCK_CUSTOM_SOCKOPT
bit, thus handling SOL_SOCKET option operations, but all of them except
SO_ZEROCOPY will be forwarded to the generic handler by calling
'sock_setsockopt()'.

Signed-off-by: Arseniy Krasnov <AVKrasnov@xxxxxxxxxxxxxx>
---
Changelog:
v4 -> v5:
 * This patch is totally reworked. Previous version added check for
   PF_VSOCK directly to 'net/core/sock.c', thus allowing to set
   SO_ZEROCOPY for AF_VSOCK type of socket. This new version catches
   attempt to set SO_ZEROCOPY in 'af_vsock.c'. All other options
   except SO_ZEROCOPY are forwarded to generic handler. Only this
   option is processed in 'af_vsock.c'. Handling this option includes
   access to transport to check that MSG_ZEROCOPY transmission is
   supported by the current transport (if it is set, if not - transport
   will be checked during 'connect()').

Yeah, great, this is much better!


net/vmw_vsock/af_vsock.c | 44 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index da22ae0ef477..8acc77981d01 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1406,8 +1406,18 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr,
			goto out;
		}

-		if (vsock_msgzerocopy_allow(transport))
+		if (!vsock_msgzerocopy_allow(transport)) {

Can you leave `if (vsock_msgzerocopy_allow(transport))` and just add
the else branch with this new check?

		if (vsock_msgzerocopy_allow(transport)) {
			...
		} else if (sock_flag(sk, SOCK_ZEROCOPY)) {
			...
		}

+			/* If this option was set before 'connect()',
+			 * when transport was unknown, check that this
+			 * feature is supported here.
+			 */
+			if (sock_flag(sk, SOCK_ZEROCOPY)) {
+				err = -EOPNOTSUPP;
+				goto out;
+			}
+		} else {
			set_bit(SOCK_SUPPORT_ZC, &sk->sk_socket->flags);
+		}

		err = vsock_auto_bind(vsk);
		if (err)
@@ -1643,7 +1653,7 @@ static int vsock_connectible_setsockopt(struct socket *sock,
	const struct vsock_transport *transport;
	u64 val;

-	if (level != AF_VSOCK)
+	if (level != AF_VSOCK && level != SOL_SOCKET)
		return -ENOPROTOOPT;

#define COPY_IN(_v)                                       \
@@ -1666,6 +1676,34 @@ static int vsock_connectible_setsockopt(struct socket *sock,

	transport = vsk->transport;

+	if (level == SOL_SOCKET) {

We could reduce the indentation here:
		if (optname != SO_ZEROCOPY) {
			release_sock(sk);
			return sock_setsockopt(sock, level, optname, optval, optlen);
		}

Then remove the next indentation.

+		if (optname == SO_ZEROCOPY) {
+			int zc_val;

`zerocopy` is more readable.
+
+			/* Use 'int' type here, because variable to
+			 * set this option usually has this type.
+			 */
+			COPY_IN(zc_val);
+
+			if (zc_val < 0 || zc_val > 1) {
+				err = -EINVAL;
+				goto exit;
+			}
+
+			if (transport && !vsock_msgzerocopy_allow(transport)) {
+				err = -EOPNOTSUPP;
+				goto exit;
+			}
+
+			sock_valbool_flag(sk, SOCK_ZEROCOPY,
+					  zc_val ? true : false);

Why not using directly `zc_val`?
The 3rd param of sock_valbool_flag() is an int.

+			goto exit;
+		}
+
+		release_sock(sk);
+		return sock_setsockopt(sock, level, optname, optval, optlen);
+	}
+
	switch (optname) {
	case SO_VM_SOCKETS_BUFFER_SIZE:
		COPY_IN(val);
@@ -2321,6 +2359,8 @@ static int vsock_create(struct net *net, struct socket *sock,
		}
	}

+	set_bit(SOCK_CUSTOM_SOCKOPT, &sk->sk_socket->flags);
+
	vsock_insert_unbound(vsk);

	return 0;
--
2.25.1


_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux