[ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.

Fischetti, Antonio antonio.fischetti at intel.com
Thu May 19 14:17:42 UTC 2016


Hi Ben,
I've set up a different scenario with 10 TCP, 17 UDP, 20 ICMP, and 20 IGMP flows. 

The figures I get are

Case C: 10 TCP, 17 UDP, 20 ICMP, and 20 IGMP Flows
=================================================
Original dpcls:   2.15 Mpps
ACL + dpcls:      2.98 Mpps

For both cases I changed the code to bypass EMC.

The current ACL implementation is using rules as {ProtocolType, IPsrc, IPdest, PortSrc, PortDest}, so I'm limited to play just with these 5 fields.

Is this what you were suggesting, or is there a better scenario I could try?

Below some details on how I set up the flows.

# + 17 UDP Flows
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.20,nw_dst=34.35.36.37,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.20,nw_dst=34.35.36.38,udp_dst=44,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.19,udp_src=33,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.18,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.17,udp_dst=44,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,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.13,udp_src=33,udp_dst=44,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.10,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.9,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.8,nw_dst=34.35.36.37,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=17.18.19.8,nw_dst=34.35.36.38,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.7,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_src=17.18.19.6,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=17,nw_dst=34.35.36.37,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_dst=34.35.36.38,action=output:2

# + 10 TCP Flows
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.1,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.2,nw_dst=2.2.2.2,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.3,tcp_src=55,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.4,tcp_dst=66,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.5,nw_dst=2.2.2.5,tcp_src=55,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.6,nw_dst=2.2.2.6,tcp_dst=66,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=6,nw_src=1.1.1.7,nw_dst=2.2.2.7,tcp_src=55,tcp_dst=66,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=1.1.1.8,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_src=1.1.1.9,nw_dst=2.2.2.9,action=output:2
ovs-ofctl add-flow br0 dl_type=0x0800,nw_dst=2.2.2.10,action=output:2

# + 20 ICMP Flows
for i in `seq 1 20`;
do
    ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=1,nw_src=3.3.3.$i,action=output:2
done

# + 20 IGMP Flows
for i in `seq 1 20`;
do
    ovs-ofctl add-flow br0 dl_type=0x0800,nw_proto=2,nw_src=5.5.5.$i,action=output:2
done


Thanks,
Antonio

> -----Original Message-----
> From: Ben Pfaff [mailto:blp at ovn.org]
> Sent: Monday, May 2, 2016 10:16 PM
> To: Fischetti, Antonio <antonio.fischetti at intel.com>
> Cc: dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for
> Wildcard matching.
> 
> 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,acti
> on=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=out
> put: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=out
> put: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=out
> put: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:blp at ovn.org]
> > > Sent: Thursday, April 21, 2016 7:41 PM
> > > To: Fischetti, Antonio <antonio.fischetti at intel.com>
> > > Cc: dev at 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.fischetti at 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?



More information about the dev mailing list