Andrew Gallatin writes: > > 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.
If it's done right, you should end up in a place that's no _worse_ than the current situation, where we just copy everything always. I agree that it could be done badly, and the collapse effect you're describing would be the result. > It is far better to have the driver copy buffers if he runs low. That gets you into an ugly starvation problem, and the copies still happen. > > 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. Right ... though at least with the socket applications, we have a bit more local control by modifying sockfs itself. In any event, the picture for queued packets isn't pretty unless the driver has a _lot_ of memory available for this sort of usage. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
