From: Jarno Rajahalme [mailto:ja...@ovn.org] Sent: Friday, May 20, 2016 8:59 PM To: Fischetti, Antonio <antonio.fische...@intel.com> Cc: Jan Scheurich <jan.scheur...@ericsson.com>; Ben Pfaff <b...@ovn.org>; dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.
On May 20, 2016, at 4:07 AM, Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>> wrote: One question below about data on real use-cases, thanks. -----Original Message----- From: Jarno Rajahalme [mailto:ja...@ovn.org] Sent: Thursday, May 19, 2016 7:51 PM To: Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>> Cc: Jan Scheurich <jan.scheur...@ericsson.com<mailto:jan.scheur...@ericsson.com>>; 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 19, 2016, at 9:15 AM, Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>> wrote: Hi Jan, thanks for your feedback, some replies below. Regards, Antonio -----Original Message----- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Thursday, May 19, 2016 3:55 PM To: Fischetti, Antonio <antonio.fische...@intel.com<mailto:antonio.fische...@intel.com>>; Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> Cc: dev@openvswitch.org<mailto:dev@openvswitch.org> Subject: RE: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching. Hi, The current ACL implementation is using rules as {ProtocolType, IPsrc, IPdest, PortSrc, PortDest}, so I'm limited to play just with these 5 fields. From experience with real-world OVS deployments using bonded interfaces and overlay tunnels (e.g. VXLAN) I would say that the vast majority of dpif megaflows match on packet metadata like in_port, recirc_id, hashes, tunnel header etc. [Antonio F] In general, ACL tables can collect this type of data, they're not limited to the 5-tuple I'm using now. Given that, I wonder if an ACL-based cache can be the right tool to accelerate the megaflow lookup, especially also looking at the ACL reconfiguration times. [Antonio F] I agree, this solution would give no benefit if the addition of new flows is 'very' frequent. Do you know in a real scenario how often - more or less - we would typically need to add new flows? I mean, is it something that happens - say a tens of times within an hour? Or 1,000 times per minutes? In the worst case it can be 1,000s of times per second, e.g., during a port scan with the presence of an ACL that matches on L4 ports. [Antonio F] Do you have some data on table flows, measurements or any figures for real use-cases? That would help a lot to understand what can happen in a real scenario. Sorry, no. I have no real data for this. I think the real scenario is very dependent on the deployment and use case. If OVS is only used as an L2 switch then there would be less megaflow churn, compared to a case that deploys L3/L4 ACLs. But even with L2 only the megaflows will time out in 1.5 seconds if there is no traffic between a specific pair of L2s. Depending on the traffic pattern this alone can produce many megaflow changes per second. [Antonio F] Thanks, that helps to have a better picture. Do you know if this is something constant that happens continuously, or is it just a peak load that may happen occasionally from time to time? Furthermore, OVS can manage more than 200000 megaflows, do you know how long the recomputation would take in that case? [Antonio F] I made some measurements in terms of cpu cycles, I used 5-tuples rules {Protoc.Type, IPsrc, IPdest, PortSrc, PortDest} With 1000 entries the rebuild requires approx. 66,000,000 CPU cycles. With 10,000 entries => 1,500,000,000 CPU cycles. So it requires seconds! Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
