diff options
author | Jason A. Donenfeld <Jason@zx2c4.com> | 2018-07-18 17:26:03 +0200 |
---|---|---|
committer | Jason A. Donenfeld <Jason@zx2c4.com> | 2018-07-18 18:34:47 +0200 |
commit | 646df74bfaf31d836817c41f047d71a9903fd316 (patch) | |
tree | 7500aa0b45e6e4f247a0e60bce72763eb51915ae /contrib/external-tests | |
parent | device: destroy workqueue before freeing queue (diff) | |
download | wireguard-monolithic-historical-jd/remove-per-peer-queues.tar.xz wireguard-monolithic-historical-jd/remove-per-peer-queues.zip |
queueing: remove per-peer queuesjd/remove-per-peer-queues
Previously, having many peers would result in many napi structs, which
could make lookups in the napi_hash in net/core/dev.c slow. So, we move
to using a single napi struct per device.
The best solution would be to replace napi_hash with an idr or just get
rid of it all together and use straight pointers. However, that isn't the
case currently, so we work with what is and begrudgingly remove per-peer
queues. On the upside, it means we reduce the per-peer memory usage by
about 8k/16k, but on the downside it means that napi_gro_receive is
called on a unified list, which might result in less GRO speedups on
systems with many peers active at once.
However, if napi_hash does ever go away, we should consider reverting
this commit.
Since this means moving to unified packet queues, flushing at peer
removal is something of a problem. So we make the slightly dubious
modification of just not flushing, and letting our reference counters do
the work. This in turn required some small changes to ensure that the
reference counter will, at some point in the future, still reach zero,
and not be kept alive by non-stop packet ingress.
Co-developed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Diffstat (limited to 'contrib/external-tests')
0 files changed, 0 insertions, 0 deletions