> On May 20, 2016, at 4:07 AM, Fischetti, Antonio <antonio.fische...@intel.com> > wrote: > > One question below about data on real use-cases, > thanks. > >> -----Original Message----- >> From: Jarno Rajahalme [mailto:ja...@ovn.org <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> 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>; Ben Pfaff >>>> <b...@ovn.org> >>>> Cc: 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. Furthermore, OVS can manage more than 200000 megaflows, do you know how long the recomputation would take in that case? Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
