[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