In the patch in attachment you can find a "proof of concept" about the improvements for vde_switch packets queue management I did (the interesting part is in packetq.c). Sincerely, I don't know if it works as I expect, but the road test isn't bad. To better say, I'm almost sure it does not work as I expect (probably loss of data in type conversion), but the fact I obtain less OOO packets and better throughput UDP/TCP means something better can be done here.
The basic idea is to change the TIMEOUT dynamically, based on the current queue status to avoid queue fullness. "If the queue is filling up, try to manage it more frequently". As I stated somewhere else, the microsecond resolution of poll is not enough, please consider to switch to ppoll coupled with clock_gettime instead of gettimeofday. At present I use queue length as status reference, but (see commented code) you will find I tried to base this on the queue "crossing" (elaboration) time. More time queue management takes, more frequently the management should be started (lowering the timeout). Because of the free cpu time vde_switch process leaves free, complex and smart managements are possible and should give better throughput/loss/OOOpckts performance. Notice that this free cpu-time can be due to weird behavior of the program and an eye must be kept open on this. The TIMES of retransmission should be dynamic too in my opinion and/or under user control. And about the fact that if a packet cannot be transmitted "now" the management pass to the next packet may not be ever the best. "Passing to the next" is likely better for UDP (only when different packet sizes are present of course, that is the normal condition though), "Retrying until transmit" is likely better for TCP... But here we are going to design more a good router than a standard switch... Of course, as stated somewhere else, one queue per-port is much better and fair. I did not have time to read the interesting documentation you posted, but a good knowledge of how real switches work is a good start point. Even if it's very interesting, I do not have anymore so much time to spend on this work. I have to stop putting new irons in the fire at the moment. Of course I wait your replies. Regards Simone 2011/2/25 Daniele Lacamera <r...@danielinux.net>: > On Fri, Feb 25, 2011 at 08:37:35AM +0100, Daniele Lacamera wrote: >> tail and a RED implemented as separate modules, don't know if they can be >> useful. RED is very difficult to implement, so I had basically stolen that >> from linux implementation ;). >> > > Forgot to mention: I had also ported the tbf (token bucket) from linux tc, > you will find all those modules in the vde_l3 dir. > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > vde-users mailing list > vde-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/vde-users >
vde_patch.patch
Description: Binary data
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
_______________________________________________ vde-users mailing list vde-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vde-users
