OpenBSD Journal

u2k15: mpi@ on network SMPization cleanup

Contributed by pitrh on from the the twisty little paths dept.

Our next u2k15 report comes from Martin Pieuchot (mpi@):

As expected I did not do any UTF-8 related task during u2k15... Instead I sat in the network^Wfunky room to continue working on unlocking the network stack.

I was really happy to arrive in Berlin without any known fallout from unlocking the first parts of code to the process incoming packets. These parts correspond to what was previously known as ether_input() and include all the pseudo-drivers input routines. I must admit that after all the crazy changes we did during l2k15 I was really prepared to back out this commit. But since nothing showed up, I worked on the next logical step.

I spent most of my time with bluhm@ doing the necessary plumbing to ensure that resources obtained from a route lookup are always valid as long as a CPU processing packets in the hot path need to access them. As explained two years ago my ground work has been to limit the number of globally accessible data structures to a single one: the routing table. So the idea is to convert all the lookups in the hot path to use the routing table and then turn the routing table lookups' code MP-safe.

And that's exactly what Alexander did in ``in_arpinput()'' as a result of our work during u2k15.

We now have to make sure the interface pointers obtained from route entries are always valid to be able to take ``in_arpinput()'' outside of the KERNEL_LOCK.

Once this is done the next big step is pf_test() which should allow us to unlock the IPv4 forwarding path... Stay tunned!

I'd like to thank Stefan Sperling for organising this awesome hackathon and IN-Berlin for hosting us.

Thanks for the report, Martin! The work you did here looks awesome!

(Comments are closed)


Comments
  1. By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net

    Excellent steps in the right direction. Merci beaucoup.

    Are you familiar with next-hop indirection & prefix-independent convergence?

    http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/forwarding-indirect-next-hops.html (Crisco calls it "cef table output-chain build indirection")
    & more docs on PIC: https://google.com/search?q=prefix+independent+convergence

    Basically the general idea is that the network stack resolves the next-hops/adjacencies first, and associates a pointer with these adjacencies. When a convergence event happens, the box only needs to update the pointer's resolution to point to the new next-hop, so that the routes in the table don't need to have their next-hops changed in order to continue forwarding.

    I mention this because you're modifying the route lookup architecture, & your homogenization of route-lookups sounds like a good fit for next-hop indirection. An intermediate next-hop pointer could be implemented MP-safe from the beginning...

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.]