OpenBSD Journal

n2k15: mpi@ on MP networking progress

Contributed by pitrh on from the a multiplicity of tubes dept.

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

We found two kind of MP bugs!

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

MP is hard so let's sing!

n2k15 was a terribly productive hackathon... At least in songs! I'm not sure Reyk (reyk@) was prepared to have more than 10 developers from all over the world singing in the kitchen of K14, but that's the price to pay when you provide Glühwein and have a piano and an organ in the hackroom.

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.

Thanks for the report, Martin!

(Comments are closed)


Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]