rpc.tlsservd: provide parallelism with help of pthread(3)

[glebius]

Summary

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.

[glebius]

Use pthread_detach() to avoid memory leak.

[glebius]

Limit number of concurrent threads for TLS handshakes. Reuse -N option
to override the default.

[markj]

usr.sbin/rpc.tlsservd/rpc.tlsservd.c

112

266

Why is this necessary?

268

pthread_join() to reclaim the thread?

376

Maybe set ctx = NULL here.

[glebius]

Address review.

[glebius]

usr.sbin/rpc.tlsservd/rpc.tlsservd.c

266

The internal libc variable __isthreaded is 0 until you create your first thread. The new RPC svc_nl needs to see __isthreaded as 1 on initialization to allow future parallel calls into its send method.

[rmacklem]

Looks ok to me but I do not know pthreads.
Maybe markj@ can complete a review, since he
has already commented on the code?

[glebius]

In D48570#1112656, @rmacklem wrote:

Looks ok to me but I do not know pthreads.
Maybe markj@ can complete a review, since he
has already commented on the code?

If you don't mind, I'd like to push changes today. I will be online through the weekend and not disrupted by usual work & weekday stuff, so will be able to address any issues that may be discovered.

[rmacklem]

In D48570#1112658, @glebius wrote:

In D48570#1112656, @rmacklem wrote:

Looks ok to me but I do not know pthreads.
Maybe markj@ can complete a review, since he
has already commented on the code?

If you don't mind, I'd like to push changes today. I will be online through the weekend and not disrupted by usual work & weekday stuff, so will be able to address any issues that may be discovered.

I don't have a problem with this. Good luck with the pushes.