On Fri Sep 29, 2023 at 1:26 AM AEST, Aaron Conole wrote: > Nicholas Piggin <npig...@gmail.com> writes: > > > Dynamically allocating the sw_flow_key reduces stack usage of > > ovs_vport_receive from 544 bytes to 64 bytes at the cost of > > another GFP_ATOMIC allocation in the receive path. > > > > XXX: is this a problem with memory reserves if ovs is in a > > memory reclaim path, or since we have a skb allocated, is it > > okay to use some GFP_ATOMIC reserves? > > > > Signed-off-by: Nicholas Piggin <npig...@gmail.com> > > --- > > This represents a fairly large performance hit. Just my own quick > testing on a system using two netns, iperf3, and simple forwarding rules > shows between 2.5% and 4% performance reduction on x86-64. Note that it > is a simple case, and doesn't involve a more involved scenario like > multiple bridges, tunnels, and internal ports. I suspect such cases > will see even bigger hit. > > I don't know the impact of the other changes, but just an FYI that the > performance impact of this change is extremely noticeable on x86 > platform.
Thanks for the numbers. This patch is probably the biggest perf cost, but unfortunately it's also about the biggest saving. I might have an idea to improve it. Thanks, Nick _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
