At Tue, 2 Jun 2015 11:47:01 -0700, Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost> wrote: Subject: Re: Removing ARCNET stuffs > > It's too long an argument, but I think any approach to a > multiprocessor network stack that attempts to get there starting > with the existing network L2/L3/interface code as a base is likely > not on the table. I would offer the rather herculean effort spent > on FreeBSD to attempt to do exactly that, and the fairly mediocre > result it produced, as evidence. The resources to match that > probably don't exist, and if there were a better, easier way to do > this it would have been done already. I think the least cost way to > produce a better result is actually to make a big change, preserving > the device drivers and the transport protocol code (which needs to run > single-threaded per-socket in any case) and any non-IP protocol code > that still works (running single-threaded) but doing a wholesale > replacement of the code that moves packets between those things with > something that can operate without locks. Doing it this way has some > risks, not the least of which is that it would leave you with networking > code unlike anyone else's (though if it were well done I'm not sure this > would last, everyone has trouble with the network stack), but I think > this makes the problem tractable and has a good chance of producing > something that scales quite well even without a lot of Linux-style > micro-optimization effort. Dennis, if you are able I wonder if you could comment on how well you think the NetGraph implementation in FreeBSD fares with respect to being part of a multiprocessor network stack, and if you think it offers any advantages (and/or has any disadvantages) in an SMP environment. I understand that NetGraph gained some finer-grained SMP support as early as FreeBSD-5.x. I also read about some NetGraph locking and performance issues in the 201309DevSummit notes, but I don't know any of the details. What if NetGraph was the _only_ network stack in the kernel? And what about Luigi Rizzo's netmap? (which claims to be specifically targeted at multi-core machines) (I'm going to try to learn a bit more about netmap at BSDCan this year.) And finally, what about the possibilities for a more formal STREAMS-like implementation, or at least something that would be compatible with existing STREAMS modules at the API (DDI/DKI) level, w.r.t. SMP? This would maybe allow independent maintenance and testing of less widely used protocol modules (and perhaps even drivers) by third parties. -- Greg A. Woods Planix, Inc. <woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpu3AAi_pWrI.pgp
Description: PGP signature