bridge project update (Week of March 9th)

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