Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Dec 1997 03:11:57 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        bakul@torrentnet.com (Bakul Shah)
Cc:        luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
Subject:   Re: Why FIONREAD has no dual for write ?
Message-ID:  <199712100311.UAA04169@usr06.primenet.com>
In-Reply-To: <199712091519.KAA09117@chai.torrentnet.com> from "Bakul Shah" at Dec 9, 97 10:19:37 am

next in thread | previous in thread | raw e-mail | index | archive | help
> [Just stating the obvious...] The idea behind high/low
> watermark is to introduce a _hysteresis_ effect.  You want an
> advance notice about when buffers may get empty/full so that
> you can produce/consume sufficient data before they actually
> get empty/full.  By choosing the watermarks judiciously you
> can *minimize* the overhead and still keep data flowing.
> This is something sorely missing from poll() and select().

The problem with doing this is that it should be up to the driver,
not up to the user.  The problem here is that what you are really
describing is "pool retention time", and that varies based on the
driver, and based on compute overhead per polling period.

So once again, the user space code isn't portable.

I suppose you could ask the driver what it preferred, but then why
not make the driver act that way by default.  I think all this
attempt to move batching into the kernel only makes things too
complicated.

Even if the driver says "I can accept N bytes *now*", by the time you
send the bytes, it may be well past "now".  The driver *must* rely on
private buffer resources in order to be able to make any guarantees.

As far as how many bytes it can accept when it says it can accept
bytes... dev_bsize seems to me to be the obvious answer.

At worst, you should consider using readv/writev.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712100311.UAA04169>