bridge project update (Week of March 9th)
Kristof Provost
kp at FreeBSD.org
Sun Mar 15 11:34:18 UTC 2020
Hi,
As this is the first status report sent to a wider audience I’ll try
to give a bit of background information.
I’m working on a performance improvement project for if_bridge. Right
now it’s a big bottleneck for a number of different scenarios (e.g.
for VNET jail or VM hosts).
if_bridge currently has a single mutex to protect its internal data
structures. As a result it’s nowhere near as fast as it could be.
I’ve started the project by adding a number of tests to ensure that I
don’t break things (or at least not everything) during this project.
A number of tests have already been committed. One more will go in soon
(https://reviews.freebsd.org/D23961). They all live in
/usr/tests/sys/net/if_bridge_test.
Aside from that I’ve been investigating the possibility of using the
NET_EPOCH to improve bridge throughput. It’s very early, of course,
but I’m investigating the possibility of keeping the bridge lock, but
removing it from bridge_input/bridge_output/… (i.e. the data path),
instead relying on NET_EPOCH to ensure that the important data
structures don’t go away while we’re processing packets.
Part of that work was building my own understanding of how the epoch
system is supposed to work. Very briefly (and with the caveat that
I’ve only just started looking at it): Use lockless lists (CK_*).
Objects should remain valid (i.e. not free()d) in between
NET_EPOCH_ENTER() and NET_EPOCH_EXIT(). To accomplish this the object
can be freed through a NET_EPOCH_CALL() callback, which will only be
done once all CPUs have left their NET_EPOCH_(ENTER|EXIT) sections. This
requires an epoch_context, which can best be placed in the to-be freed
structure.
Feel free to get in touch if you have questions, remarks or suggestions.
Best regards,
Kristof
More information about the freebsd-current
mailing list