Hello Simon, Yes, you’re right. We are indeed targeting hardware offload. Since there are limitations when using TCAMs, bypassing them can help optimize both lookups and the forwarding process.
Best, Farhan ________________________________ From: Simon Horman <[email protected]> Sent: Monday, September 16, 2024 6:45 PM To: Farhan Tariq <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [ovs-dev] [RFC PATCH 1/3] exact-match-offload: Introducing Exact-Match HW Offload Support for OVS On Thu, Sep 12, 2024 at 12:51:27PM +0000, Farhan Tariq wrote: > This patch introduces exact-match offload support in OVS to enhance > optimization for hardware datapath. It's being submitted as a RFC for early > feedback. > > Problem Statement: > Currently, OVS offloads megaflows using tc-flower. However, hardware > support for megaflows has certain limitations: > a. TCAMs are used, which aren't scalable and support fewer rules. > b. Using hash tables to emulate TCAMs results in complex and slow > performance with many tables. > > Solution: > This patch aims to add exact-match offload support to OVS, addressing > these issues. This feature is an optional enhancement and is disabled by > default. > > Implementation Details: > 1. Added a new flag, "exact-match-offload" to "ovs-vsctl...other_config", > which is disabled by default but can be enabled at runtime. It works only > if megaflows are disabled. > 2. Introduced the "enable_exact_match_offload()" API in > "/lib/netdev-offload-tc.c" to zero-out unused masks. > 3. Moved "enable_megaflows" from "ofproto/ofproto-dpif-upcall.c" to "lib/- > netdev-offload-tc.c" to make it visible in the "netdev-offload-tc.c" > file. An alternate implementation could be to use a getter api. > > Testing results: > Verified the basic functionality of the patch with different flows. > > Future Work: > 1. Add support for connection tracking. > 2. Add support for OVS-DPDK rte_flow. > > Note: This feature does not affect user OpenFlow tables. > --- > Potential Issue: > This patch might not handle short-lived large numbers of new connections > effectively. The last proposal (i.e. proposal #4 listed below) can address > this issue. For now this feature is beneficial for many use cases, with > further optimization for handling large numbers of short-lived connections > planned for future work. > > Other Possible Solutions: > Several approaches to implementing exact-match offload are being > considered. Comments are welcome on the best approach: > 1. Offload all fields except mutable and unpredictable ones (e.g., ttl, > tos, ip_frag, checksum). Megaflows are disabled. > 2. Offload only essential fields (e.g., 5-tuple + VLAN IDs + tunnel info > etc). Megaflows are disabled. > 3. Provide configuration options for users to select which fields to > offload. Megaflows are disabled. > 4. Introduce an offloading path from the OVS datapath (kernel) module to > integrate megaflows and exact-match offload, addressing short-lived new > connection performance. Suggestions on this approach are welcome. > -- > Co-authored-by: Farhat Ullah > <[email protected]<mailto:[email protected]>> > Signed-off-by: Farhat Ullah > <[email protected]<mailto:[email protected]>> > Signed-off-by: Farhan Tariq > <[email protected]<mailto:[email protected]>> Thanks Farhat, A high level, am I correct in thinking that the motivation for this is hardware where rules are stored in TCAMs. Which, for the reasons you describe above, achieve better results with exact-match rules than mega-flows. Not strictly related, but, it seems that for some reason the CI checks didn't run. Hopefully this will result in them running. Recheck-request: github-robot _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
