Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Nov 2000 14:06:20 -0500 (EST)
From:      Bosko Milekic <bmilekic@dsuper.net>
To:        David Malone <dwmalone@maths.tcd.ie>
Cc:        freebsd-net@freebsd.org
Subject:   Re: M_RDONLY: review & comment
Message-ID:  <Pine.BSF.4.21.0011191352310.15213-100000@jehovah.technokratis.com>
In-Reply-To: <200011121319.aa19357@salmon.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help

  Hi,

  	Sorry for this relatively late review; I was bogged down with a lot
  of studying this past week.

On Sun, 12 Nov 2000, David Malone wrote:

> This is an application of the M_WRITABLE macro I've been testing
> at home (we're also testing a cruder version in RELENG_4 in college).
> What this does is allows sbcompress to compress into external
> storage if it is writable.

	OK. This sounds good, although I would only introduce it, at this
  point, to -CURRENT. We can wait for this release to go through before
  looking at a MFC.

> This can be of great help if you have lots of small packets arriving
> via an interface which always uses an mbuf cluster for every packet
> (the fxp driver is one example I think). We were frequently running
> out of clusters before using this patch.

	Exactly... this is great!

> The limit of copying at most MCLBYTES/4 comes from BSDi, which seems
> to have had a similar patch in place for some time. If Bosko or someone
> can review this I'd like to commit it.

	I have a couple of mainly stylistic remarks... see below.

> 	David.
> 
[...]
> +		    (m)->m_len <= MCLBYTES / 4 &&
> +		    (m)->m_len <= M_TRAILINGSPACE(n) &&
[...]

	Firstly, why is it necessary to place paranthesis around the mbuf
  pointer, m?
  	Secondly, even though the (MCLBYTES / 4) is reasonable, I would put a
  small comment above that, just in case we end up changing the mbuf or
  cluster size in the distant future, so that people browsing the code will
  immediately guess that it may need to be changed. This is entirely up to
  you, so if you feel that it's not needed, feel free to leave as is.

	Other than that, this looks good. I'm building a kernel with it right
  now and will stress the machine a bit and get back to you within the next
  1.5 hours... if nothing seriously evil occurs, feel free to commit at
  your convenience.

  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.0011191352310.15213-100000>