Date: Fri, 01 Sep 2000 14:02:07 -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.0009011335340.1476-100000@jehovah.technokratis.com> In-Reply-To: <200009010907.aa78923@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009011335340.1476-100000>