At normal NFS server runtime there is not much RPC traffic from kernel to
rpc.tlsservd. But as Rick rmacklem@ explained, the notion of multiple
workers exists to handle a situation when a server reboots and it has
several hundred or thousands of TLS/TCP connections from clients. Once it
comes back up, all the clients make TCP connections and do TLS handshakes.
So cleanup the remnants of the workers, that left after the conversion of
RPC over netlink(4) transport and restore desired parallelism with help of
pthread(3).
We are processing the TLS handshakes in separate threads, one per
handshake. This is a minimal implementation: we aren't keeping a pool of
threads, neither pre-allocating them, nor limiting their count. This
should be sufficient to dynamically size thread count. This might be
redesigned later.