WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/net?h=jd%2Fqueueboosts 2020-06-23T04:31:03Z 2020-06-23T04:31:03Z Jason A. Donenfeld Jason@zx2c4.com 2020-06-23T04:21:54Z urn:sha1:fb099766628c04eb037969aacdcb0ff94b4cfe4f This enables us to process queueing of different packet queues in without NET_LOCK. Combined with the increase in txlen, this keeps our encryption workers more active. This results in a ~30% performance boost. 2020-06-23T04:24:09Z Jason A. Donenfeld Jason@zx2c4.com 2020-06-23T04:18:04Z urn:sha1:1807dd1a1529b4426d7d3c99a4709bbf7598d19e This increases throughput by keeping the worker threads active for longer. 2020-06-22T12:20:44Z jasper jasper@openbsd.org 2020-06-22T12:20:44Z urn:sha1:3ea0ed4d4443963148a75c6f3135e9c96b1d09dd 2020-06-22T10:01:03Z mvs mvs@openbsd.org 2020-06-22T10:01:03Z urn:sha1:5cb27655b6fa9fff13c366871caeee1bbd1d1352 - There is no panic() condition while inserting `pxi' to tree so drop RBT_FIND() to avoid two lookups. - Modify text in panic() message in delete case. ok yasuoka@ claudio@ 2020-06-22T09:45:13Z claudio claudio@openbsd.org 2020-06-22T09:45:13Z urn:sha1:2646c3b95731d186ec4b1bff5cd3c1458c6f5139 For example the bridge_ioctl() function calls NET_UNLOCK() unconditionally and so calling if_ioctl() without netlock will trigger an assert because of not holding the netlock. Make sure the ioctl handlers are called with the netlock held and drop the lock for the wg(4) specific ioctls in the wg_ioctl handler. This fixes a panic in bridge_ioctl() triggered by ifconfig(8) issuing a SIOCGWG ioctl against bridge(4). This is just a workaround this needs more cleanup but at least this way the panic can not be triggered anymore. OK stsp@, tested by semarie@ 2020-06-22T09:38:15Z mvs mvs@openbsd.org 2020-06-22T09:38:15Z urn:sha1:0dd8107de1f079472b4a1e690b378b6a322c553e sessions by pipex_iface_fini() or by pipex_ioctl() with `PIPEXSMODE' command. ok yasuoka@ 2020-06-22T03:07:57Z dlg dlg@openbsd.org 2020-06-22T03:07:57Z urn:sha1:54392b432564fd4419250c5bcde62d5189f1cb51 livelock detection used to rely on code running at softnet blocking the softclock handling at a lower interrupt priority level. if the hard clock interrupt count diverged from one kept by a timeout, we assumed the network stack was doing too much work and we should apply backpressure to the receptions of packets. the network stack doesnt really block timeouts from firing anymore though. this is especially true on MP systems, because timeouts fire on cpu0 and the nettq thread could be somewhere else entirely. this means network activity doesn't make the softclock lose ticks, which means we aren't scaling rx ring activity like we think we are. the alternative way to detect livelock is when a driver queues packets for the stack to process, if there's too many packets built up then the input routine return value tells the driver to slow down. this enables finer grained livelock detection too. the rx ring accounting is done per rx ring, and each rx ring is tied to a specific nettq. if one of them is going too fast it shouldn't affect the others. the tick based detection was done system wide and punished all the drivers. ive converted all the drivers to the new mechanism. let's see how we go with it. jmatthew@ confirms rings still shrink, so some backpressure is being applied. 2020-06-21T12:11:26Z dlg dlg@openbsd.org 2020-06-21T12:11:26Z urn:sha1:58360b13e88a8f23faf2a04ee8f459832fd7e8d8 thanks to Matt Dunwoodie and Jason A. Donenfeld for their effort. it's at least as functional as the go implementation, and maybe more so since this one works on more architectures. i'm sure there's further development that can be done, but you can say that about anything and everything that's in the tree. ok deraadt@ 2020-06-21T11:25:54Z dlg dlg@openbsd.org 2020-06-21T11:25:54Z urn:sha1:ccc6f9dd43f8194fd2b1dd43787cfaaf2c3c8862 i'm still not a fan of the peer semantics of wireguard interfaces where each interface can have multiple peers and each peer has a set of the allowed ips configurred, aka cryptokey routing. traditionally we would use a tunnel (IFT_TUNNEL) style interface per peer, which means there's a 1:1 mapping between a peer and an interface. in turn that means you can apply policy with things like pf to the interface and it implies policy on the peer. so allowed ips inside a wg interface feels like a bandaid for a self inflicted wound to some degree. however, deraadt@ points out that the boat has sailed, and being compatible with the larger ecosystem has benefits. admins can choose to setup an interface per peer if they want too, so we get the best of both worlds. i will admit an interface per peer sucks in a concentrator situation though. that's why we still have pppac(4) as well as pppx(4). i also don't have any better ideas for how to scale or even express this kind of policy in a concentrator setting either. apologies for the teary. from Matt Dunwoodie and Jason A. Donenfeld ok deraadt@ 2020-06-19T08:48:15Z dlg dlg@openbsd.org 2020-06-19T08:48:15Z urn:sha1:3a046e31010b3c2151debfebceede0c9a295fd5a ix(4) wants an array of uint32_ts to push into 32bit registers.