> On May 4, 2016, at 3:56 AM, Fischetti, Antonio <antonio.fische...@intel.com> > wrote: > > Hi Jarno, my reply inline. > > Thanks, > Antonio > >>> For more details, please let me know. >>> >> >> The flows above are at the OpenFlow level. I guess your test traffic >> exercises (just) the corresponding datapath flows? >> >> Do you know how much of the performance gain is lost once you add >> support not just for the IPv4 5-tuple, but all the different fields >> supported by struct flow (metadata, L2, IPv6, ARP, IGMP, etc)? > > [Antonio F] > I didn't make these kind of tests yet, for now I restricted > my tests focusing only on the wildcard matching for megaflows. > I tried to exclude any other aspect that could affect the > overall performance, I wanted to check if this solution is > really an improvement for the wildcard matching. > > When we consider that also other tables are involved, the lookups and > jumps between ofproto tables, EMC lookups and so on, > of course the performance gain will have less impact on the overall > system. > > The performance figures are just for the IPv4 5-tuple, but I needed > to share the idea and have some feedback from the Community > before moving forward. >
I’ve found that typically you have to implement the whole thing to find out if it makes a significant difference or not. This solution as proposed could be characterized as another cache between the EMC cache and the megaflow classifier. One major factor that will determine its usefulness is the fraction of time it is operational in a realistic traffic situation. I haven’t fully read the code, but it seems to me that DPDK-ACL lookup can only be done if there are no pending changes to the megaflows. Since there typically is high churn in the megaflow classifier due to it being reactive to the actual network traffic, especially if compared to the OpenFlow classifier, which is reactive to configuration and policy changes only, the fraction of time when the DPDK-ACL can be operational might be low. If you were able to change the DPDK-ACL structure to allow fast removal (i.e., by marking an entry invalid), it might be possible to keep it operational as a cache on front of the megaflow classifier at all times; if there is a miss on the DPDK-ACL, then we would proceed to do a lookup in the megaflow classifier. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
