From: Jarno Rajahalme [mailto:ja...@ovn.org] Sent: Thursday, May 5, 2016 7:45 PM To: Fischetti, Antonio <antonio.fische...@intel.com> Cc: Ben Pfaff <b...@ovn.org>; dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.
On May 5, 2016, at 9:27 AM, Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>> wrote: Thanks for your feedback, Jarno. Replies inline. From: Jarno Rajahalme [mailto:ja...@ovn.org] Sent: Wednesday, May 4, 2016 7:23 PM To: Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>> Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>; dev@openvswitch.org<mailto:dev@openvswitch.org> Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching. On May 4, 2016, at 3:56 AM, Fischetti, Antonio <antonio.fische...@intel.com<mailto: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 themegaflow classifier. [Antonio F] That’s an interesting idea. 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. [Antonio F] Exactly, or when a ‘rebuild’ is in progress. An ACL insertion is a 2-step process: the insertion itself and then the so-called ‘rebuild’. The rebuild may require a lot of cpu cycles, it depends on how many entries are already in the table. I made some measurements, with 1000 entries the rebuild requires approx. 66,000,000 CPU cycles. With 10,000 entries => 1,500,000,000 CPU cycles. If the DPDK-ACL was a cache, then we could limit the number of entries to something that makes sense. [Antonio F] That’s interesting. If I understand well your idea is that at the start up we should use the original dpcls and populate ACL in the background. After a limit of entries is reached, or after some time limit, the ACL cache is ready to work between the EMC and the dpcls. At this point no further entry can be added, deletion can be made as ‘fast’ deletions by deleting the intermediate-table entries. Since there typically is high churn in the megaflow classifier [Antonio F] TBH I don’t know exactly how much frequent are the Flow insertions/removals in a real scenario. In the worst case each new L4 connection may require a megaflow update. This should not be typical, though, as we strive to generate megaflows that are not 5-tuple specific. due to it being reactive to the actual network traffic, especially if compared to the OpenFlowclassifier, 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 themegaflow classifier. [Antonio F] Unluckly ACL doesn’t allow to update its entries. Right, but when an entry is found, it could be marked as “deleted” outside of the ACL, meaning that a megaflow classifier lookup needs to be made. [Antonio F] That can be easily done as it is now. ACL can store {key, value} entries where the value is 32bit long. When an entry is found the value is not a pointer to the Flow, it’s just an index to an intermediate table, which is an array of Flow pointers. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
