> On May 5, 2016, at 9:27 AM, Fischetti, Antonio <antonio.fische...@intel.com> > wrote: > > Thanks for your feedback, Jarno. Replies inline. > <> > <>From: Jarno Rajahalme [mailto:ja...@ovn.org <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. > 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. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
