Date: Tue, 27 Jun 2000 18:34:02 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: mbuf re-write(s): v 0.2: request-for-comments Message-ID: <Pine.BSF.4.21.0006271756020.535-100000@jehovah.technokratis.com>
next in thread | raw e-mail | index | archive | help
Hello, I just added a MEXTADD() routine to the [now getting bigger] mbuf re-write patch, as well as fixed and changed a few little things here and there (once again). Thus, so-called "version 2" of the diff is again available: http://www.technokratis.com/code/mbuf/ This code includes all that was discussed in the previous Email, as well as a better/actually working external storage facility for clusters. Previously, it was very difficult to allocate external storage, attach it to the mbuf, _and_ as well maintain a reference counter for it, primarily due to the arguments that were taken by ext_free() and ext_buf(). These have been changed to have a new void * pointer passed in as the second argument (following the base address of the storage buffer). Also has been included a void * multi-purpose ext_args pointer in the m_ext struct, so the caller has much more flexibility now. In fact, the caller can now attach a "management" or "reference" structure to the m_ext struct via the ext_args pointer, and have it passed to his ext_free and ext_buf routines. Naturally, for dynamically sized malloc() external buffers, the caller can also allocate along with it space for its reference counter and attach to the mbuf via the ext_args pointer. It will be incremented/decremented properly as ext_args can be passed as the second argument to the two functions. When ext_free, ext_buf, and ext_args are all NULL, but M_EXT is set, then the external storage corresponds to an mcluster. These changes will surely help out/make cleaner some code, like some of Bill Paul's device drivers (if_sk, if_ti, if_wb). For other purposes, such as sf_bufs, for example, it's not _as_ significant, mainly since sf_bufs are allocated from their own map such that the system can easily produce a unique index for a reference counter array just by looking at the offset base_addr_of_sf_buf - base_addr_of_map, like we do for mclusters. However, obviously, we don't want a new map for every new type of external storage we want to attach to an mbuf. :-) (Yes, this means easy attaching of dynamically sized buffers) What I still have left to do before I look into finding/bugging/annoying a committer (sigh) to reviewing/committing all of this: * Re-write the mcluster allocations/deallocations in the same style as the new mbuf allocator/deallocator. ... If someone has a more suitable proposition, please let me know. I love to hear suggestions. * I'm thinking of adopting NetBSD's "cute" and "clean" reference count system; they maintain their mbufs linked through the m_ext when they reference the same storage object. This will remove all fear from external callers/code having to deal with references in the first place, and will isolate it all to the mbuf code. Once this is done, I can also add a NetBSD-like MEXTMALLOC() macro, in addition to the just-added MEXTADD() macro. This would automate dynamic malloc()ing of external storage objects, and make it quite a bit cleaner/easier for the caller. * Patch up userland to deal with all of these changes. * Get some profiling / optimisation done. Since my initial post, I have received quite a few hits/requests for the posted code, and have even received a few comments/suggestions. These have been most helpful. I invite many more,... please! Regards, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.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.0006271756020.535-100000>