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. > 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. Drew _______________________________________________ networking-discuss mailing list [email protected]
