Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Sep 2004 08:03:03 +0200
From:      Waldemar Kornewald <Waldemar.Kornewald@web.de>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        FreeBSD-net <freebsd-net@freebsd.org>
Subject:   Re: locking & iovecs
Message-ID:  <4153B897.9040807@web.de>
In-Reply-To: <20040923211703.GA23574@odin.ac.hmc.edu>
References:  <4152A3E9.8080700@web.de> <20040923181605.GC25699@odin.ac.hmc.edu> <415339A1.6090905@web.de> <20040923211703.GA23574@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

Bye,
Waldemar Kornewald



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4153B897.9040807>