Next up in our continuing series of n2k15 hackathon reports comes one from Martin Pieuchot (mpi@), who writes:

There are MP bugs that you fix without even understanding them, and there are MP bugs that you understand but can't fix.

There's two bigs issues left in the forwarding path: IPSec and pf(4). So I discussed with Markus (markus@) about IPSec and with Alexandr (sashan@) and Mike (mikeb@) about pf(4). In both cases my primary concern is not about the technical solution to adopt but about the "way" to move forward. I'm interested in the engineering effort. The question I have is: How can we make progress in parallel when changing interdependent subsystems?

Yes, I'm trying to de-serialize the MP efforts ;)

Sadly we could not come with a better solution that putting a single lock around the subsystems. The problem was not really what to do, but how to start doing it. Having a single lock makes it easy for developers to see where is the limit of a critical section. Then you can start moving the limit further and further.

With the help of Claudio and Alexander (bluhm@) we killed the last usages of ``rt_ifp'' which allowed me to replace the interface pointer stored in route entries by an unique index. That means that the MPLS stack is now mpsafe and you can already try a diff for ARP.

I also fixed some smalls bugs in ART and with the help of Sebastian (benno@) I could adjust the memory consumption of this new routing table backend. A -current kernel compiled with option ART should now consume almost as much memory as a kernel with a radix-tree for a fullfeed BGP box. Do not hesitate and try it now! ART will became the default routing table backend, so I'm interested in test reports. Plus during that week, Jonathan (jmatthew@) and I also cooked some diffs to turn it mpsafe!

But since Claudio was already testing unlocked MPLS performances I also cooked a diff to reduce the contention on the KERNEL_LOCK when we use the radix-tree. This is far from being ideal as we're potentially grabbing and releasing a mutex multiple times per packet, but it allows you to experiment.

Apart from the usual cleanups and Ken (krw@)'s USB bugs, I broke some ports using kvm(3) for reading interface status and names. After bitching on 90's code I rewrote some bits using getifaddrs(3). Thanks to J�r�mie (jca@), Jasper (jasper@) and Gleydson (gsoares@) for taking care of the other ports! In the end we have fewer ports linking to the libkvm which is a good thing!

Funny I thought I didn't do anything and only played music during this week, but writing a report shows you the truth.

Thanks a lot to Reyk for hosting us in its delightful place and to the Foundation for taking care of the hotel.