Oh, now that we talk about alternatives: did you consider using iovecs instead of mbufs? Be Inc. said that BONE, the new netstack of BeOS (now Zeta), can handle huge amounts of data much better than mbufs because iovecs reduce the number of copies made when fragmenting...though, there has never been a real comparison.
Rewriting the network stack to use an alternate method of storing network data is a hugh undertaking. It's not an idea that's likely to get any sort of traction in the project unless someone presented running code and a massive performance improvement across the entire spectrum of applications. Unless you mean splitting buffers up into TCP packets, fragmentations is a network configuration bug in 99% of all cases. :)
Sorry, that is no bug. :)
Maybe we will try it after we get our code/port stable. As we will not port all of your protocols it should be less of a problem to change our stack. I can post the results here (in some years ;).
You can implement mutexes using semaphores, but semaphores tend to be a more expensive since they are more expressive them mutexes.
Using a benaphore instead would improve speed significantly and as you only use macros we can easily replace those with our benaphore code, is that really so simple? Sorry, I cannot believe that. :)
Once GIANT is really gone, it may be nearly that easy. We're a ways from that though.
So, the code is not fully thread-safe yet (we want to drop GIANT)? Then, I misunderstood something. Will 5.3 be freed of GIANT?
Bye, Waldemar Kornewald _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
