Hi, I am experiencing an interesting problem with my STREAMS modules implementation. Here is a brief description.
I have a multiplexing driver D that acts as a special-purpose data router. An application opens the driver, then accepts TCP connections from clients and also establishes TCP connections to some predefined servers. For each established connection several modules M are pushed onto that process data in passing. After that the stack is pushed to the bottom queue of the driver to allow data multiplexing. Here is how data flow looks like: TCP -> M1 -> M2 -> D -> M3 -> M1 -> TCP As you can see the module M1 is used on top of TCP for both incoming and outgoing data. All modules use the STREAMS flags (D_NEW|D_MP|D_MTPERMOD). When a newly received packet mblk is passed by the TCP to the module M1 wput, it is passed all the way to M3 via the putnext calls. I traced the function call flow with a dtrace script. Then in M3, when the putnext is invoked, the qfill_syncq is called. I looked at the putnext source code in opensolaris, then traced it more with dtrace trying to determine what causes this. I came to the conclusion that since M3 is trying to invoke M1 again, it cannot do so (since we are still inside an M1 rput call and due to MTPERMOD perimeter mode) and thus putnext calls qfill_syncq to push the message onto the module synchronization queue. Is my conclusion correct? If yes, would creating a separate M4 instead of M1 solve this (so that the qfill_sync is not invoked?) There are several reasons I don't want this behavior: normal STREAMS flow control is not functioning since the normal STREAMS queue is not used to back up extra traffic. Also invoking qfill_syncq on every message is probably costly (though CPU utilization is almost 0) and sync queue can grow very quickly before it is drained, eventually causing QFULL condition. Are there other approaches to solving this puzzle? Would appreciate any ideas. Thank you, Leonti Dailis SS8 Networks _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
