From owner-freebsd-hackers Tue Dec 9 19:12:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06481 for hackers-outgoing; Tue, 9 Dec 1997 19:12:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA06460 for ; Tue, 9 Dec 1997 19:12:33 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id UAA21264; Tue, 9 Dec 1997 20:16:30 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd021248; Tue Dec 9 20:16:27 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id UAA04169; Tue, 9 Dec 1997 20:11:57 -0700 (MST) From: Terry Lambert Message-Id: <199712100311.UAA04169@usr06.primenet.com> Subject: Re: Why FIONREAD has no dual for write ? To: bakul@torrentnet.com (Bakul Shah) Date: Wed, 10 Dec 1997 03:11:57 +0000 (GMT) Cc: luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <199712091519.KAA09117@chai.torrentnet.com> from "Bakul Shah" at Dec 9, 97 10:19:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [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.