Andrew Gallatin wrote:
James Carlson writes:
>
> In other words, have putq(9F) check for an 'indirect' mblk (one that
> points to a dblk with this special tied-down hardware dependency) in
> the chain, and if it's one of those, then do copyb(9F) on each special
> one or copymsg(9F) on the whole thing, and free the original.
Note that I know very little about streams, but if you're suggesting
what I think you, that's very similar to what currently happens in
windows, and you *really* don't want to do that. The problem is that
a lot of applications don't pre-post receive buffers, so if an
application gets even a little behind, you'll start copying. This will
cause things to get even more behind, and performance will collapse.
It is far better to have the driver copy buffers if he runs low.
The problem is that this situation ties the driver and devinfo node in
memory, making it impossible for the administrator to do a dynamic
reconfiguration operation, even after having unplumbed the NIC.
> Notably, that tied-down mblk problem happens with user-space
> applications. You can open a driver with snoop, ^Z the snoop process,
> then walk away. What should the driver do in that case, when all its
> receive resources get tied up in service of buffers sitting on the
> STREAMS read head queue for days or weeks?
And a non-root user can ^Z a bunch of applications with large
socket buffer sizes and achieve the same thing. In this case,
the driver needs to allocate more memory, or copy to generic
allocb'ed buffers itself.
Again, more problems with loan-up buffers.
-- Garrett
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
