On 01/22/2017 09:07 PM, Jan Scheurich wrote: > Hi Kevin > >>> The performance results are very impressive - it looks like ~50% >>> performance improvement after about 10K flows. >>> >>> Did you measure any negative effects when the the emc is not full? >> Hi Kevin, >> >> When the EMC is not full the impact is negligible. >> For example I tested with 1, 128 & 1024 flows and measured a -0.04% >> degradation and +2% and +1% improvement with the patch. > > If the bulk of your traffic consists of only a few, albeit very > short-lived (<< 100 packets) parallel flows, you will likely measure a > negative impact as the probability for these flows to be inserted into > the EMC and subsequent packets be expedited decreases. We haven't been > able to quantify this effect due to a lack of a traffic generator for > such a traffic pattern. In the worst case the performance could degrade > to that of a pure Megaflow classifier with EMC disabled. With the latest > improvements on the performance of the DPCLS, the degradation should not > be dramatic any longer. >
Hi Jan, sorry for delay. Thanks for the explanation. I think there is still a big drop between emc and dplcls, but agree the scenario above is worst case and it may not be worth the effort of adding to the emc for such a small amount of packets. >>> What about about only using this type of scheme once the emc is full or >>> above a certain threshold? >> Given the above results I don't think implementing something like that >> is necessary. The adof ditional logic could be what ends up degrading >> performance. >> >> Thanks, >> Ciara >> > We though about this a lot but decided to avoid the complexity and > run-time overhead of making this scheme adaptive. The fill level of the > EMC alone is not sufficient as criterion to reduce the insertion > probability. One would also have to increase the probability again with > a decreasing hit rate to recover from the situation from a completely > filled but outdated EMC. > > I'd suggest to go for this simple and extremely robust scheme first > (wi h the addition to make the insertion probability configurable) and > make it adaptive later, should the need arise and someone have a clever > idea how to get it right. Sounds reasonable. Kevin. > > Jan _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
