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> > 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 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. > > > >> > >> 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. > > > > I had thought of sorting the subtables periodically, but never got to > do anything about it. Actually, I'd like to see how that performs > compared to the ACL proposal before deciding what to do. > > dpcls already uses struct pvector to store the subtables. It would be > rather easy to use the pvector API to assign a 'priority' > corresponding to the hit count and then sort the subtables > accordingly and publish the newly ordered pvector for the pmd thread > to use for lookups. The only extra fast path cost would be the > incrementing of subtable hit counts. > > Would the fact that each pmd thread has it's own dpcls take care of > the separation per ingress port? I.e., if performance matters then > maybe each port has its own pad thread? > > Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
