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? > > What we do see, however is that there is often a strong correlation > between the ingress port and the subset of masks/subtables that have > hits. The entire megaflow cache typically decomposes nicely into > partitions that are hit only by packets entering from equivalent > ports (e.g. traffic from Phy -> VM and VM -> Phy) > > Since megaflows are by nature non-overlapping, the search can stop at > the first match. Keeping a separate list of subtables per ingress > port, sorted by frequency of hits, should reduce the average number > of subtables lookups to a minimum, even if the total number of > subtables gets large. > > Has such an idea been considered? [Antonio F] This approach sounds interesting. > > /Jan > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
