To me, it was that the existing code mostly worked and had already proved to be a real performance improvement. This coupled with the limited manpower we could pour on the project. I understand that turning a single-threaded program into a multi-threaded one looks scary, and with reason. On the other end, reworking the main loop of the bridge looks just as scary, and there is still the risk to be disappointed by the final performance.
More positively, this approach only affects the userlevel datapath, which is also the one that really needs a performance boost. A change in the main loop of the bridge would be much more intrusive, I think, since all datapaths would likely need to be touched. Il giorno 28/set/2012, alle ore 20:48, Jesse Gross <je...@nicira.com> ha scritto: > I haven't been following this work all that closely but earlier on > there was a discussion of how the performance benefits might be > related to how poll is used. Restructuring that seems like a much > more desirable path but I never saw any real follow up. What was the > reason for continuing to go down this path? Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 2, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.letti...@iet.unipi.it _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
