Date: Fri, 21 Feb 2003 15:07:43 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Hiten Pandya <hiten@unixdaemons.com>, FreeBSD-arch@FreeBSD.ORG Subject: Re: Mbuf flags cleanup proposal Message-ID: <20030221150743.A79345@unixdaemons.com> In-Reply-To: <3E5673E7.F3F1FA4F@mindspring.com>; from tlambert2@mindspring.com on Fri, Feb 21, 2003 at 10:45:59AM -0800 References: <20030221151007.GA60348@unixdaemons.com> <3E5673E7.F3F1FA4F@mindspring.com>
index | next in thread | previous in thread | raw e-mail
For What It's Worth:
On Fri, Feb 21, 2003 at 10:45:59AM -0800, Terry Lambert wrote:
> Hiten Pandya wrote:
> > Gang. I have a proposal to rename the current mbuf subsystem
> > flag bits as follows:
> >
> > mbuf (sys/mbuf.h) flags:
> >
> > M_TRYWAIT -> MB_TRYWAIT
> > M_DONTWAIT -> MB_DONTWAIT
>
> [ ... ]
>
> > Any reasonable objections/comments?
>
> 1) This seems to move away from integration of UVA and the
> mbuf allocator.
You mean UMA. And this has absolutely nothing to do with it. There
are several other reasons that the move is most likely not going to
happen (they are cited at the top of the most recent subr_mbuf.c in
the comments). I wish people read those more often and stopped
blindly recommending where and to what things should move towards,
without providing reasonable solutions to the problems that actually
arise when TRYING to do what they suggest. In other words, talk is
cheap, dirt cheap.
> 2) It seems to me that all code should be moving to non-blocking
> interfaces, and blocking interfaces should be deprecated.
>
> 3) "TRYWAIT" is really useless; either I can depend on blocking
> until the request is satisfied, or I can't; if I can't, then
> I might as well not have the extra complication of "wait a
> little bit, and then fail anyway": it doesn't make my code
> any less complicated.
The behavior has absolutely nothing to do with your code. It's not an
API thing, it's the default behavior of the allocator which tries to
wait at least a little bit to see if it can recover during an
exhaustion before giving up. I agree with you when you say that the
networking code[1] should be taught to deal with failure (however
"drastic" its dealing with it is is irrelevant), but that should not be
sufficient reason to preclude the allocator from at least trying
harder when it's in a tight spot.
[1] This is what I infer you're saying from this post and this
earlier one:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=333614+0+archive/2003/ \
freebsd-arch/20030126.freebsd-arch
> -- Terry
As for the flags renaming, although I would like to see it, Sam made
a good point in the first response to this post. Now let's just let
it die and move on to bigger and better things.
--
Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030221150743.A79345>