locking & iovecs
Waldemar.Kornewald at web.de
Thu Sep 23 23:04:39 PDT 2004
Brooks Davis wrote:
>>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?
More information about the freebsd-net