Hi, Jumping in late (but better than never I hope). I have recently discussed some of these issues with Kacheong in relation to the following CR:
http://bugs.opensolaris.org/view_bug.do?bug_id=6497245 If affected by this issue it is easy to workaround by disabling fusion, tuning the socket buffers (as previously indicated by Adi Masputra, the mblk hiwater mark is derived from the value of SO_SNDBUF divided by an empirically determined value (16k)) or adjusting tcp_fusion_rcv_unread_min. Some of this is documented in info doc 86046. I think any long term 'solution' to this must, by it's very nature, be an adaptive one (we are already criticising the incumbent static solution). Moreover, I don't think any of the evidence put forward so far is particularly compelling in terms of highlighting any real world functional deficiencies. The main problem, IMHO, is one of documented versus actual behaviour. If you have an endpoint with a send buffer of, say, 64k the expectation is that you can write up to 64k without blocking. With fusion, if this write is broken up into multiple system calls, this is not guaranteed. Using a fusion endpoint is not an elective choice and the semantics ARE different. This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
