WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/net/if_loop.c?h=jd%2Fqueueboosts 2020-01-08T09:09:10Z 2020-01-08T09:09:10Z claudio claudio@openbsd.org 2020-01-08T09:09:10Z urn:sha1:5a1e6e9cca10b92c3bc0eebbdb1f9084c3258d0d the if_detach() call. In if_detach() various route messages are generated and during that time the rtable_l2() mapping needs to stay. OK kn@ 2019-08-06T22:57:54Z bluhm bluhm@openbsd.org 2019-08-06T22:57:54Z urn:sha1:8f6d2e8bf0b541dc10865826bab4d248a2639690 introduced a queue to grab the lock for multiple packets. Now we have only netlock for both IP and protocol input. So the queue is not necessary anymore. It just switches CPU and decreases performance. So remove the inet and inet6 ip queue for local packets. To get TCP running on loopback, we have to queue once between TCP input and output of the two sockets. So use the loopback queue in looutput() unconditionally. OK visa@ 2018-09-09T10:11:41Z henning henning@openbsd.org 2018-09-09T10:11:41Z urn:sha1:f7ebbf1968980cdd64cdfb5eae828056fdbc0634 deleted if the rdomain doesn't contain any other interface. turn the rdomain back into an ordinary, empty rtable in that case. with this and the previous commits one can get rid of rdomains again without rebooting, which wasn't possible any more for some time ok bluhm, input mpi 2018-03-02T15:52:11Z claudio claudio@openbsd.org 2018-03-02T15:52:11Z urn:sha1:0869a26642f378154f5112a742a66abc8ed6eea8 This needs to go back to the drawing board. 2018-02-10T05:32:21Z claudio claudio@openbsd.org 2018-02-10T05:32:21Z urn:sha1:d62081b6dd05a67ee176092f85ee96e83eb74a19 as loopback interfaces for each rdomain (including lo0). This is done when the interface is brought up. This is now also done by default (either on attach of lo0 or when creating the rdomain). OK mpi@ 2018-01-09T15:24:24Z bluhm bluhm@openbsd.org 2018-01-09T15:24:24Z urn:sha1:809d3a3e7e4e2167dd03620b8ad7b0a18aaebb7d memory shortage. As it is invoked from a system call, it should not fail and wait instead. OK visa@ mpi@ 2017-12-15T01:37:30Z dlg dlg@openbsd.org 2017-12-15T01:37:30Z urn:sha1:ea47e5e1b6d67781cc4f61bd0240820384903832 currently there is a single mbuf_queue per interface, which all rings on a nic shove packets onto. while the list inside this queue is protected by a mutex, the counters around it (ie, ipackets, ibytes, idrops) are not. this means updates can be lost, and reading the statistics is also inconsistent. having a single queue means that busy rx rings can dominate and then starve the others. ifiqueue structs are like ifqueue structs. they provide per ring queues, and independent counters for each ring. when ifdata is read for userland, these counters are aggregated. having a queue per ring now allows for per ring backpressure to be applied. MCLGETI will have it's day again. right now we assume every interface wants an input queue and unconditionally provide one. individual interfaces can opt into more. im not completely happy about the shape of this atm, but shuffling it around more makes the diff bigger. ok visa@ 2017-10-31T22:05:12Z sashan sashan@openbsd.org 2017-10-31T22:05:12Z urn:sha1:93865884b36eca9fa138a35d5f936254a8f76e4d NOTE: code still runs with single softnet task. change definition of SOFTNET_TASKS in net/if.c, if you want to have more than one softnet task OK mpi@, OK phessler@ 2017-10-19T11:02:42Z bluhm bluhm@openbsd.org 2017-10-19T11:02:42Z urn:sha1:c0a69b8ad4bcb9d884249062cf1e23117af1224b removed some queueing. lo(4) output called the ip input routines without a queue. So if a packet looped through the kernel, the kernel stack filled up. Use M_LOOP to find recursive calls to looutput(). This flag is set when a packet goes through the loopback interface. Avoid an additional queueing if the packet goes to lo(4) only once. As there may be gif(4), bridge(4), pair(4), ipsec(4), rdomain(4), ... setups that legitimately pass lo(4) more than once, use the interface input queue for these cases. Packets in the queue run through ip forward. There the TTL is decremented and the packet is finally processed or dropped. found by markus@; OK mpi@ sashan@ 2017-04-19T15:21:54Z bluhm bluhm@openbsd.org 2017-04-19T15:21:54Z urn:sha1:9b6a64127deb1b83dcff3be06f373dc1b5768659 No binary change. OK mpi@