Date: Sun, 10 Sep 2000 11:09:36 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Julian Elischer <julian@elischer.org> Cc: net@FreeBSD.ORG Subject: Re: mbuf system with mutexes Message-ID: <Pine.BSF.4.21.0009101052370.954-100000@jehovah.technokratis.com> In-Reply-To: <39BB5A14.167EB0E7@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[trimmed -current, only sending to -net] On Sun, 10 Sep 2000, Julian Elischer wrote: > Assuming we have a "my processor" index somewhere, > how much work would it take to give each processor a > separate cache of mbufs? This was the intent from the beginning. Alfred originally suggested it. Personally, I'm waiting for things with SMP to sort of stabalize more before taking a stab at it. That work would be considered more as optimization work and since we have quite a bit to yet optimize/make run faster, I was told that it could wait - and I agree. Better to have things work _properly_ and then go for making them work faster and optimally. > Also, I've often wondered if the 'cluster' special code might > more simply be implemented by puting pointers to cluster methods > in the mbuf external method pointers and removing all the special > case tests to see if it's a cluster. In that case there > would be just 2 cases: > non-external and external, where 'cluster mbufs' are only > a presupplied external type. This is a good idea. We would have to make sure also that the non-subsystem code doesn't make assumptions about the external storage of an mbuf as much, either. I primarily like this idea, not only for the simplicity that it will help bring to the system, but also because it would allow us to work on freeing clusters back to the map when no longer needed, and when we want to, and leaving the mbuf allocator to do its own stuff. I would now argue that leaving mbufs on a purely cached list (i.e. not freeing them back to mb_map) is a good idea, as they are small anyway. However, I still have those thoughts of having clusters eventually freed back, as long as it doesn't have too much of a performance impact. Finally, it would be a good idea to see with the socket zero-copy code guys if it would be worth doing something like what was done with the jumbo frame bufs that they have, and attempt some sort of generlization in order to minimize code bloat. Since I'm replying to you, I'd like to ask you a question. :-) You implemented the > PAGE_SIZE mcluster kproc stuff, right? Is this stuff still usable? (I know that we have certain issues with using contigmalloc()). > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009101052370.954-100000>