Date: Thu, 31 Aug 2000 21:33:09 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: David Malone <dwmalone@maths.tcd.ie> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <Pine.BSF.4.21.0008312119030.387-100000@jehovah.technokratis.com> In-Reply-To: <200008310954.aa57200@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Aug 2000, David Malone wrote: > At the time external storage is first attached to a mbuf you can set > M_RDONLY if it must never be written to (eg. sendfile bufs or parts > of the NFS zero copy stuff might want to do similar). If the M_RDONLY > flag is set you must not write to the buffer, otherwise you can write > to the buffer if it's a simple mbuf or if the reference count on the > external storage is 1. > > (Atleast, this is the system I had in mind). 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. 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. 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. If you decide to not sacrifice the extra 4 bytes per MEXT mbuf, then you will have slower execution time, as the macro does a much longer check, which you must do in every case, but the one which finds the RDONLY bit already set. 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. 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.0008312119030.387-100000>