Peter Memishian wrote:
> > When using libdlpi, if a link is opened (dlpi_open), and bound to a
> > given sap (dlpi_bind), I strongly suspect that all matching messages
> > (packets) on that link are queued for consumption (using dlpi_recv()
> > to drain the queue).
>
> Yes.
>
> > What I can't find is what happens if too many messages get queued
> > before dlpi_recv() can drain them -- the obvious thing is to drop
> > subsequent packets until there's enough room to enqueue more, but how
> > would one detect that condition?
>
> The packets will queue up at the stream head until it's full. They will
> then queue up at each downstream module with a service procedure -- in
> order -- until all queues are filled. At that point, the driver (GLDv3 if
> the driver uses it) will find that canputnext() returns zero when it
> attempts to pass the packet upstream, and it will drop packet.
>
And the way to detect that is usually a kstat (usually "oflo", at least
for GLDv3, but note that "norcvbuf" could be interesting in such
situations as well) in the NIC driver.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
