summaryrefslogtreecommitdiffstats
path: root/gnu/usr.bin/clang/llvm-config/LibraryDependencies.inc.Sparc
diff options
context:
space:
mode:
authordlg <dlg@openbsd.org>2019-03-04 21:57:16 +0000
committerdlg <dlg@openbsd.org>2019-03-04 21:57:16 +0000
commit74c96e4dbfbfbfee951fce45400940e2ee1526f7 (patch)
tree9c059b5ecd569dbdbad54088723d424c653c4875 /gnu/usr.bin/clang/llvm-config/LibraryDependencies.inc.Sparc
parentAfter vmm(4) max name length has been increased, adapt vmd(8) config (diff)
downloadwireguard-openbsd-74c96e4dbfbfbfee951fce45400940e2ee1526f7.tar.xz
wireguard-openbsd-74c96e4dbfbfbfee951fce45400940e2ee1526f7.zip
move back to ifiq_input counting packets instead of queue operations.
the backpressure seems to have kicked in too early, introducing a lot of packet loss where there wasn't any before. secondly, counting operations interacted extremely badly with pseudo-interfaces. for example, if you have a physical interface that rxes 100 vlan encapsulated packets, it will call ifiq_input once for all 100 packets. when the network stack is running vlan_input against thes packets, vlan_input will take the packet and call ifiq_input against each of them. because the stack is running packets on the parent interface, it can't run the packets on the vlan interface, so you end up with ifiq_input being called 100 times, and we dropped packets after 16 calls to ifiq_input without a matching run of the stack. chris cappuccio hit some weird stuff too. discussed with claudio@
Diffstat (limited to 'gnu/usr.bin/clang/llvm-config/LibraryDependencies.inc.Sparc')
0 files changed, 0 insertions, 0 deletions