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

[Fischetti, Antonio]

Thanks for your feedback, Jarno. Replies inline.

From: Jarno Rajahalme [mailto:jarno at ovn.org]
Sent: Wednesday, May 4, 2016 7:23 PM
To: Fischetti, Antonio <antonio.fischetti at intel.com>
Cc: Ben Pfaff <blp at ovn.org>; dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.


On May 4, 2016, at 3:56 AM, Fischetti, Antonio <antonio.fischetti at intel.com<mailto:antonio.fischetti at intel.com>> wrote:

Hi Jarno, my reply inline.

Thanks,
Antonio


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)?

[Antonio F]
I didn't make these kind of tests yet, for now I restricted
my tests focusing only on the wildcard matching for megaflows.
I tried to exclude any other aspect that could affect the
overall performance, I wanted to check if this solution is
really an improvement for the wildcard matching.

When we consider that also other tables are involved, the lookups and
jumps between ofproto tables, EMC lookups and so on,
of course the performance gain will have less impact on the overall
system.

The performance figures are just for the IPv4 5-tuple, but I needed
to share the idea and have some feedback from the Community
before moving forward.


I’ve found that typically you have to implement the whole thing to find out if it makes a significant difference or not.

This solution as proposed could be characterized as another cache between the EMC cache and the megaflow classifier.
[Antonio F] That’s an interesting idea.

One major factor that will determine its usefulness is the fraction of time it is operational in a realistic traffic situation. I haven’t fully read the code, but it seems to me that DPDK-ACL lookup can only be done if there are no pending changes to the megaflows.
[Antonio F] Exactly, or when a ‘rebuild’ is in progress.
An ACL insertion is a 2-step process: the insertion itself and then the so-called ‘rebuild’.
The rebuild may require a lot of cpu cycles, it depends on how many entries are already in the table.
I made some measurements, with 1000 entries the rebuild requires approx. 66,000,000 CPU cycles.
With 10,000 entries  => 1,500,000,000 CPU cycles.

Since there typically is high churn in the megaflow classifier
[Antonio F] TBH I don’t know exactly how much frequent are the Flow insertions/removals in a real scenario.

due to it being reactive to the actual network traffic, especially if compared to the OpenFlow classifier, which is reactive to configuration and policy changes only, the fraction of time when the DPDK-ACL can be operational might be low.

If you were able to change the DPDK-ACL structure to allow fast removal (i.e., by marking an entry invalid), it might be possible to keep it operational as a cache on front of the megaflow classifier at all times; if there is a miss on the DPDK-ACL, then we would proceed to do a lookup in the megaflow classifier.
[Antonio F] Unluckly ACL doesn’t allow to update its entries.

  Jarno