Documentation/networking/kcm.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 =============================
   4 Kernel Connection Multiplexor
   5 =============================
   6
   7 Kernel Connection Multiplexor (KCM) is a mechanism that provides a message based
   8 interface over TCP for generic application protocols. With KCM an application
   9 can efficiently send and receive application protocol messages over TCP using
  10 datagram sockets.
  11
  12 KCM implements an NxM multiplexor in the kernel as diagrammed below::
  13
  14     +------------+   +------------+   +------------+   +------------+
  15     | KCM socket |   | KCM socket |   | KCM socket |   | KCM socket |
  16     +------------+   +------------+   +------------+   +------------+
  17         |                 |               |                |
  18         +-----------+     |               |     +----------+
  19                     |     |               |     |
  20                 +----------------------------------+
  21                 |           Multiplexor            |
  22                 +----------------------------------+
  23                     |   |           |           |  |
  24         +---------+   |           |           |  ------------+
  25         |             |           |           |              |
  26     +----------+  +----------+  +----------+  +----------+ +----------+
  27     |  Psock   |  |  Psock   |  |  Psock   |  |  Psock   | |  Psock   |
  28     +----------+  +----------+  +----------+  +----------+ +----------+
  29         |              |           |            |             |
  30     +----------+  +----------+  +----------+  +----------+ +----------+
  31     | TCP sock |  | TCP sock |  | TCP sock |  | TCP sock | | TCP sock |
  32     +----------+  +----------+  +----------+  +----------+ +----------+
  33
  34 KCM sockets
  35 ===========
  36
  37 The KCM sockets provide the user interface to the multiplexor. All the KCM sockets
  38 bound to a multiplexor are considered to have equivalent function, and I/O
  39 operations in different sockets may be done in parallel without the need for
  40 synchronization between threads in userspace.
  41
  42 Multiplexor
  43 ===========
  44
  45 The multiplexor provides the message steering. In the transmit path, messages
  46 written on a KCM socket are sent atomically on an appropriate TCP socket.
  47 Similarly, in the receive path, messages are constructed on each TCP socket
  48 (Psock) and complete messages are steered to a KCM socket.
  49
  50 TCP sockets & Psocks
  51 ====================
  52
  53 TCP sockets may be bound to a KCM multiplexor. A Psock structure is allocated
  54 for each bound TCP socket, this structure holds the state for constructing
  55 messages on receive as well as other connection specific information for KCM.
  56
  57 Connected mode semantics
  58 ========================
  59
  60 Each multiplexor assumes that all attached TCP connections are to the same
  61 destination and can use the different connections for load balancing when
  62 transmitting. The normal send and recv calls (include sendmmsg and recvmmsg)
  63 can be used to send and receive messages from the KCM socket.
  64
  65 Socket types
  66 ============
  67
  68 KCM supports SOCK_DGRAM and SOCK_SEQPACKET socket types.
  69
  70 Message delineation
  71 -------------------
  72
  73 Messages are sent over a TCP stream with some application protocol message
  74 format that typically includes a header which frames the messages. The length
  75 of a received message can be deduced from the application protocol header
  76 (often just a simple length field).
  77
  78 A TCP stream must be parsed to determine message boundaries. Berkeley Packet
  79 Filter (BPF) is used for this. When attaching a TCP socket to a multiplexor a
  80 BPF program must be specified. The program is called at the start of receiving
  81 a new message and is given an skbuff that contains the bytes received so far.
  82 It parses the message header and returns the length of the message. Given this
  83 information, KCM will construct the message of the stated length and deliver it
  84 to a KCM socket.
  85
  86 TCP socket management
  87 ---------------------
  88
  89 When a TCP socket is attached to a KCM multiplexor data ready (POLLIN) and
  90 write space available (POLLOUT) events are handled by the multiplexor. If there
  91 is a state change (disconnection) or other error on a TCP socket, an error is
  92 posted on the TCP socket so that a POLLERR event happens and KCM discontinues
  93 using the socket. When the application gets the error notification for a
  94 TCP socket, it should unattach the socket from KCM and then handle the error
  95 condition (the typical response is to close the socket and create a new
  96 connection if necessary).
  97
  98 KCM limits the maximum receive message size to be the size of the receive
  99 socket buffer on the attached TCP socket (the socket buffer size can be set by
 100 SO_RCVBUF). If the length of a new message reported by the BPF program is
 101 greater than this limit a corresponding error (EMSGSIZE) is posted on the TCP
 102 socket. The BPF program may also enforce a maximum messages size and report an
 103 error when it is exceeded.
 104
 105 A timeout may be set for assembling messages on a receive socket. The timeout
 106 value is taken from the receive timeout of the attached TCP socket (this is set
 107 by SO_RCVTIMEO). If the timer expires before assembly is complete an error
 108 (ETIMEDOUT) is posted on the socket.
 109
 110 User interface
 111 ==============
 112
 113 Creating a multiplexor
 114 ----------------------
 115
 116 A new multiplexor and initial KCM socket is created by a socket call::
 117
 118   socket(AF_KCM, type, protocol)
 119
 120 - type is either SOCK_DGRAM or SOCK_SEQPACKET
 121 - protocol is KCMPROTO_CONNECTED
 122
 123 Cloning KCM sockets
 124 -------------------
 125
 126 After the first KCM socket is created using the socket call as described
 127 above, additional sockets for the multiplexor can be created by cloning
 128 a KCM socket. This is accomplished by an ioctl on a KCM socket::
 129
 130   /* From linux/kcm.h */
 131   struct kcm_clone {
 132         int fd;
 133   };
 134
 135   struct kcm_clone info;
 136
 137   memset(&info, 0, sizeof(info));
 138
 139   err = ioctl(kcmfd, SIOCKCMCLONE, &info);
 140
 141   if (!err)
 142     newkcmfd = info.fd;
 143
 144 Attach transport sockets
 145 ------------------------
 146
 147 Attaching of transport sockets to a multiplexor is performed by calling an
 148 ioctl on a KCM socket for the multiplexor. e.g.::
 149
 150   /* From linux/kcm.h */
 151   struct kcm_attach {
 152         int fd;
 153         int bpf_fd;
 154   };
 155
 156   struct kcm_attach info;
 157
 158   memset(&info, 0, sizeof(info));
 159
 160   info.fd = tcpfd;
 161   info.bpf_fd = bpf_prog_fd;
 162
 163   ioctl(kcmfd, SIOCKCMATTACH, &info);
 164
 165 The kcm_attach structure contains:
 166
 167   - fd: file descriptor for TCP socket being attached
 168   - bpf_prog_fd: file descriptor for compiled BPF program downloaded
 169
 170 Unattach transport sockets
 171 --------------------------
 172
 173 Unattaching a transport socket from a multiplexor is straightforward. An
 174 "unattach" ioctl is done with the kcm_unattach structure as the argument::
 175
 176   /* From linux/kcm.h */
 177   struct kcm_unattach {
 178         int fd;
 179   };
 180
 181   struct kcm_unattach info;
 182
 183   memset(&info, 0, sizeof(info));
 184
 185   info.fd = cfd;
 186
 187   ioctl(fd, SIOCKCMUNATTACH, &info);
 188
 189 Disabling receive on KCM socket
 190 -------------------------------
 191
 192 A setsockopt is used to disable or enable receiving on a KCM socket.
 193 When receive is disabled, any pending messages in the socket's
 194 receive buffer are moved to other sockets. This feature is useful
 195 if an application thread knows that it will be doing a lot of
 196 work on a request and won't be able to service new messages for a
 197 while. Example use::
 198
 199   int val = 1;
 200
 201   setsockopt(kcmfd, SOL_KCM, KCM_RECV_DISABLE, &val, sizeof(val))
 202
 203 BFP programs for message delineation
 204 ------------------------------------
 205
 206 BPF programs can be compiled using the BPF LLVM backend. For example,
 207 the BPF program for parsing Thrift is::
 208
 209   #include "bpf.h" /* for __sk_buff */
 210   #include "bpf_helpers.h" /* for load_word intrinsic */
 211
 212   SEC("socket_kcm")
 213   int bpf_prog1(struct __sk_buff *skb)
 214   {
 215        return load_word(skb, 0) + 4;
 216   }
 217
 218   char _license[] SEC("license") = "GPL";
 219
 220 Use in applications
 221 ===================
 222
 223 KCM accelerates application layer protocols. Specifically, it allows
 224 applications to use a message based interface for sending and receiving
 225 messages. The kernel provides necessary assurances that messages are sent
 226 and received atomically. This relieves much of the burden applications have
 227 in mapping a message based protocol onto the TCP stream. KCM also make
 228 application layer messages a unit of work in the kernel for the purposes of
 229 steering and scheduling, which in turn allows a simpler networking model in
 230 multithreaded applications.
 231
 232 Configurations
 233 --------------
 234
 235 In an Nx1 configuration, KCM logically provides multiple socket handles
 236 to the same TCP connection. This allows parallelism between in I/O
 237 operations on the TCP socket (for instance copyin and copyout of data is
 238 parallelized). In an application, a KCM socket can be opened for each
 239 processing thread and inserted into the epoll (similar to how SO_REUSEPORT
 240 is used to allow multiple listener sockets on the same port).
 241
 242 In a MxN configuration, multiple connections are established to the
 243 same destination. These are used for simple load balancing.
 244
 245 Message batching
 246 ----------------
 247
 248 The primary purpose of KCM is load balancing between KCM sockets and hence
 249 threads in a nominal use case. Perfect load balancing, that is steering
 250 each received message to a different KCM socket or steering each sent
 251 message to a different TCP socket, can negatively impact performance
 252 since this doesn't allow for affinities to be established. Balancing
 253 based on groups, or batches of messages, can be beneficial for performance.
 254
 255 On transmit, there are three ways an application can batch (pipeline)
 256 messages on a KCM socket.
 257
 258   1) Send multiple messages in a single sendmmsg.
 259   2) Send a group of messages each with a sendmsg call, where all messages
 260      except the last have MSG_BATCH in the flags of sendmsg call.
 261   3) Create "super message" composed of multiple messages and send this
 262      with a single sendmsg.
 263
 264 On receive, the KCM module attempts to queue messages received on the
 265 same KCM socket during each TCP ready callback. The targeted KCM socket
 266 changes at each receive ready callback on the KCM socket. The application
 267 does not need to configure this.
 268
 269 Error handling
 270 --------------
 271
 272 An application should include a thread to monitor errors raised on
 273 the TCP connection. Normally, this will be done by placing each
 274 TCP socket attached to a KCM multiplexor in epoll set for POLLERR
 275 event. If an error occurs on an attached TCP socket, KCM sets an EPIPE
 276 on the socket thus waking up the application thread. When the application
 277 sees the error (which may just be a disconnect) it should unattach the
 278 socket from KCM and then close it. It is assumed that once an error is
 279 posted on the TCP socket the data stream is unrecoverable (i.e. an error
 280 may have occurred in the middle of receiving a message).
 281
 282 TCP connection monitoring
 283 -------------------------
 284
 285 In KCM there is no means to correlate a message to the TCP socket that
 286 was used to send or receive the message (except in the case there is
 287 only one attached TCP socket). However, the application does retain
 288 an open file descriptor to the socket so it will be able to get statistics
 289 from the socket which can be used in detecting issues (such as high
 290 retransmissions on the socket).