Date: Tue, 10 Jul 2001 12:04:37 -0700 (PDT) From: Richard Hodges <rh@matriplex.com> To: freebsd-atm@FreeBSD.ORG Subject: HARP device drivers roll call (output return value) Message-ID: <Pine.BSF.4.10.10107101127270.20575-100000@mail.matriplex.com>
next in thread | raw e-mail | index | archive | help
The problem:
When sending an ATM PDU, HARP does a few checks on the VC and then
hands off the PDU to the device driver. The device driver needs
to figure out whether the PDU can be buffered and transmitted, or
if the PDU must be discarded. Either way, there is currently no
way for the device driver to return any kind of return status.
This does not seem to cause any problem for UBR circuits, since
the application probably does not need flow control or the higher
protocols handle flow control (eg, TCP).
CBR circuits reveal the limitations of this, however. If you have
a 64k CBR VC, the device driver must rely on the application to
regulate the data rate pretty well over the short term, and very
closely in the long term. If the application errs even slightly
on the high side, the driver will eventually have to choose between
PDU loss or mbuf starvation. Actually, these both must result
in PDU loss.
One solution:
An application that creates a CBR VC could supervise the data flow
precisely so that the driver never has to drop a PDU. One problem
with this is that the CBR circuit may have cell transmit "time slots"
that must not be missed, which implies that the VC should always have
at least one PDU buffer ready for segmentation, preferably several
buffers to make it insensitive to delays in the kernel and application.
This gives the application the task of keeping a small number of VC
buffers full, but not _TOO_ many. Since the driver has no mechanism
for feedback, the application has to do this blind.
Another solution:
The application can regulate its data flow to the VC by asking the
device driver how big the current VC buffer is. With a target
fullness number, the application can adjust its data pace to keep
the device driver buffer close to the target. This method is
workable, but requires extra system calls to collect this information.
Third solution:
The next solution is to modify the device driver and HARP so that the
device driver can return status (through HARP) to the application. It
is rather straightforward to modify the driver to check the VC buffer
(mbuf list actually) size against some arbitrary value. This value
could be compiled into the driver, set dynamically via a sysctl variable,
or possibly even set per VC with setsockopt(). In any event, the driver
can return a code (such as ENOBUFS) that the application can use to
regulate its output rate. There is no extra system call overhead, since
the buffer status is implied by the send() or sendto() return value.
I am currently working on this third solution, and I am interested in
finding out who is also working on HARP and HARP device drivers, so
that we can discuss and coordinate our work. As far as I know, there
is noone currently maintaining the hea and hfa drivers, and the other
drivers are maintained by:
Mark Tinguely (first IDT 77211 and 77201 driver)
Richard Hodges (IDT 77211 only, later driver)
Gerald Heinig (Interphase driver in development)
Is there anyone else working on a HARP drivers, or is interested
in doing so? Is anyone else interested in discussing the merits
of adding a CBR buffer feedback mechanism to HARP?
Thanks,
-Richard
-------------------------------------------
Richard Hodges | Matriplex, inc.
Product Manager | 769 Basque Way
rh@matriplex.com | Carson City, NV 89706
775-886-6477 | www.matriplex.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-atm" 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.10.10107101127270.20575-100000>