This is a significant performance advantage. Does the improvement remain with large and complex flow tables? These flow tables are very simple.
On Fri, Apr 22, 2016 at 08:21:11AM +0000, Fischetti, Antonio wrote: > Hi Ben, > below are 2 examples. > > For both cases: > * EMC was bypassed > * using a bridge with 2 dpdk ports > * I've sent data at line rate on one port and just read the received rate > on the other port, > regardless of lost packets. > > > Case A: 7 Flows > ============ > Original dpcls: 5.74 Mpps > ACL + dpcls: 7.03 Mpps > > The 7 Flows were installed as: > ovs-ofctl add-flow br0 > dl_type=0x0800,nw_src=17.18.19.20,nw_dst=34.35.36.37,action=output:2 > ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.19,action=output:2 > ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.18,action=output:2 > ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.17,action=output:2 > ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.16,action=output:2 > ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.15,action=output:2 > ovs-ofctl add-flow br0 > dl_type=0x0800,nw_src=17.18.19.14,nw_dst=34.35.36.37,action=output:2 > > > Case B: 17 Flows > ============= > Original dpcls: 2.95 Mpps > ACL+dpcls: 4.67 Mpps > > The 17 Flows were installed as: > add-flow br0 > dl_type=0x0800,nw_proto=17,nw_src=17.18.19.20,nw_dst=34.35.36.37,action=output:2 > add-flow br0 > dl_type=0x0800,nw_proto=17,nw_src=17.18.19.20,nw_dst=34.35.36.38,udp_dst=4369,action=output:2 > add-flow br0 > dl_type=0x0800,nw_proto=17,nw_src=17.18.19.19,udp_src=4369,action=output:2 > add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.18,action=output:2 > add-flow br0 > dl_type=0x0800,nw_proto=17,nw_src=17.18.19.17,udp_dst=4369,action=output:2 > add-flow br0 dl_type=0x0800,nw_src=17.18.19.16,action=output:2 > add-flow br0 dl_type=0x0800,nw_src=17.18.19.15,action=output:2 > add-flow br0 dl_type=0x0800,nw_src=17.18.19.14,action=output:2 > add-flow br0 > dl_type=0x0800,nw_proto=17,nw_src=17.18.19.13,udp_src=4369,action=output:2 > add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.10,action=output:2 > add-flow br0 dl_type=0x0800,nw_src=17.18.19.9,action=output:2 > add-flow br0 > dl_type=0x0800,nw_src=17.18.19.8,nw_dst=34.35.36.37,action=output:2 > add-flow br0 > dl_type=0x0800,nw_src=17.18.19.8,nw_dst=34.35.36.38,action=output:2 > add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.7,action=output:2 > add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.6,action=output:2 > add-flow br0 dl_type=0x0800,nw_proto=17,nw_dst=34.35.36.37,action=output:2 > add-flow br0 dl_type=0x0800,nw_dst=34.35.36.38,action=output:2 > > For more details, please let me know. > > Thanks, > Antonio > > > > > -----Original Message----- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Thursday, April 21, 2016 7:41 PM > > To: Fischetti, Antonio <antonio.fische...@intel.com> > > Cc: dev@openvswitch.org > > Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard > > matching. > > > > On Wed, Apr 13, 2016 at 10:45:09AM +0100, antonio.fische...@intel.com > > wrote: > > > The purpose of this implementation is to improve the performance > > > of wildcard matching in user-space. > > > This RFC patch shows the basic functionality, some aspects were not > > > covered yet. > > > > > > I would like to get some feedback on whether people think integrating > > > the DPDK ACL table in this manner is potentially a good solution or not. > > > > > > DPDK ACL tables show a better performance on lookup operations than the > > > Classifier. However their insertion time for new rules is unacceptable. > > > This solution attempts to combine the better performance of ACL lookups > > > with the lower insertion latency of the Classifier. > > > > How much does the performance improve? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
