I think this whole discussion really leads to one thing: Proof Of Concept code, as Kevin mentioned earlier.
"Instead of just proposing this idea without fully understanding how it would work (here on the developer mailing list), it would be much better if you wrote a small program demonstrating the technique and proving that it is possible." If worsts comes to worsts, when writing the code you will realize that it is very possible and efficient; or, the likely case of it not working and you get to figure out why and it is just one more thing that you know. :] Best of luck, -bkruse ----- Original Message ----- From: "Kevin P. Fleming" <[EMAIL PROTECTED]> To: "Asterisk Developers Mailing List" <[email protected]> Sent: Monday, May 14, 2007 5:38:09 PM (GMT-0800) America/Tijuana Subject: Re: [asterisk-dev] RTP Bridging optimization Vadim Lebedev wrote: > Now, when we agree that it IS possible to use single pipe for multiple > bridges > let's look on benefits: I did not agree that it was possible, I told you it seemed possible but would likely provide little or no benefit. > As for now Asterisk when packet arrives on a briged socket > 1. Thread switch to the reader thread > 2. read from socket + transfer of data from kernel to user > 3. thread swicth to writer thread > 4. write to socket + transfer of data from user to kernel Where are these two threads you are referring to? Asterisk call bridges happen in one thread per bridge. > Now if my proposal is implemented in the worst case we will economise 2 > thread switches, 2 user/kernel data transfers > plus we'll have much less threads in the system. > > I think we can expect pretty dramatic improvements This would only be true if your assumption about two threads per bridge were true, but it is not. The only possible benefit of your proposal would be the reduced kernel/user copying, but you've replaced it with complex pipe setup and constant creation and destruction of splice() structures in the kernel. So far you haven't demonstrated any possible significant benefit from this idea, so unless you can show us a working example where your idea produces a performance improvement in any noticeable way, I don't think you will accomplish much pursuing this theory. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
