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
