Hi all, We've observed that for high flow setup rates, the flow table becomes a bottleneck since it only allows a single writer (all CRUD flow operations take the ovs_mutex).
A solution for this is to shard the flow table. A hash function is used to know which table to query on packet ingress and on recirculate as well as to know on which table to CRUD a flow. Some bits off the flow ID are used to identify the shard. The number of shards is configured upon datapath creation. The hash function can either be programmed into the kernel (via eBPF) or known to userspace, so it can employ threads with shard-affinity. The exact hash function likely depends on the packet type: it should use the 5-tuple, so that all packets in a connection stably hash into the same flow table shard, but for tunneled packets we may only want to contemplate the tunnel key and tunnel src and dst keys. When there is just one shard configured, the hash function is constant and has no overhead. Potentially, a packet may not match any flow in the flow table it is hashed into, but could match a megaflow in another shard. This means the packet needs to go into userspace and a new flow needs to be installed. This should be minimized by the chosen hash function but it's nonetheless something to be aware of. This approach is tailored to the reactive, just-in-time flow computation model, where it's important to minimize latency and maximize throughput. Thoughts? Thanks, Duarte _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
