Date: Fri, 01 Sep 2000 09:07:19 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Bosko Milekic <bmilekic@dsuper.net> Cc: freebsd-net@FreeBSD.ORG, dwmalone@maths.tcd.ie Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <200009010907.aa78923@salmon.maths.tcd.ie> In-Reply-To: Your message of "Thu, 31 Aug 2000 21:33:09 EDT." <Pine.BSF.4.21.0008312119030.387-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> OK, well, if the system is limited to the above, and will remain so > (which is conceivable), then the single RDONLY flag + the macro should > do. The question is always performance vs. memory, though. > > If you decide to sacrifice the extra 4 bytes per MEXT mbuf, you get > faster execution time (as you are only checking for that one bit), and > this for all execution cases. You still have to check if the storage is external - so you need to make two checks. Without the extra 4 bytes the test is: #define M_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && \ (!((m)->m_flags & M_EXT) || !MEXT_IS_REF(m))) With the extra 4 bytes the test is: #define M_WRITABLE(m) (!((m)->m_flags & M_EXT) || \ ((m)->m_ext.ref_cnt->flags & M_EXT_WRITABLE)) I'd guess that we'll find the difference unmeasurable in practice, given that in the second case we'll have deal with m_ext.ref_cnt->flags in a SMP safe way when updating it, which will have to be done in the ADD_REF and REM_REF macros. > The drawbacks are the 4 byte loss and of > course, the fact that you cannot mark individual mbufs with no external > storage as read-only. But I don't see how the latter would be useful > anyway. Me neither - but you never know ;-) > The other advantage is that you can later decide the you _do_ > want to write to the external buffer and be able to remove the RDONLY bit > on-the-fly. But this isn't presently a requirement, so feel free to > consider the point moot. This could be useful in the future, but I'd be inclined to wait until we need it. Did you have any other interesting uses for M_EXT flags in mind? > In either case, I am prepared to do at least the first part of the > implementation. For the first case, I've already made the mext_descr > changes here. But reverting to the second case is very easy, as one would > assume. Diffs can be rolled out before the end of this weekend, unless > one of you guys can pull off something even sooner, in which case > please let me know. Great! Maybe Archie should say which he thinks we opt for in the beginning, and we can see if we can get some patches reviewed. (We seem to all be badly seperated by timezones, which is slowing this process down quite a bit ;-) David. 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? <200009010907.aa78923>