> On Apr 22, 2016, at 1:21 AM, Fischetti, Antonio <antonio.fische...@intel.com> > 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. >
The flows above are at the OpenFlow level. I guess your test traffic exercises (just) the corresponding datapath flows? Do you know how much of the performance gain is lost once you add support not just for the IPv4 5-tuple, but all the different fields supported by struct flow (metadata, L2, IPv6, ARP, IGMP, etc)? Jarno > 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
