From owner-freebsd-net Fri Sep 1 11: 2:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id DB1A037B43C for ; Fri, 1 Sep 2000 11:02:46 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0700F3IZA4A2@field.videotron.net> for freebsd-net@FreeBSD.ORG; Fri, 1 Sep 2000 13:58:52 -0400 (EDT) Date: Fri, 01 Sep 2000 14:02:07 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200009010907.aa78923@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 1 Sep 2000, David Malone wrote: > 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)) As we do not have a use for read-only non-external buffer mbufs (and it's less probable that we will ever need that, compared to, for example, being able to remove M_RDONLY on the fly), then you ultimately have to test for M_EXT in both cases anyway. Your second M_WRITABLE above looks bogus because I use M_RDONLY, so it will be more like: #define M_READONLY(m) ((m)->m_flags & M_EXT) && \ ((m)->m_ext.descr->perms & M_RDONLY)) will evaluate to true if the data is not to be tampered with. For the moment, I will re-work the code as per your and Ian's ideas, because it's simpler and it meets our needs. I cannot justify having to remove M_RDONLY in the middle of something. At the same time, I *will* add a type or flags variable to m_ext, as it will make things slightly cleaner at no extra expense. > 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. That is true, both would need to be wrapped such that they remove or add the flag, respectively, if the ref. count suddenly drops to 1, or increases from 1. Actually, now that you bring up SMP, you remind me that we may even have to hold a BGL when doing this, so that if the ref count happens to increase while we're at it, so that we do not end up messing things up. This is unpractical, and you're right. > 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? No, I cannot presently justify it. > 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. Okay, I will post *something* by this upcoming Monday (long weekend here!). Later, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message