On 2/15/24 14:23, Simon Horman wrote: > On Thu, Feb 15, 2024 at 09:16:38AM +0100, Jakob Meng wrote: >> On 30.01.24 10:44, Simon Horman wrote: >>> On Fri, Jan 26, 2024 at 02:24:51PM +0100, [email protected] wrote: >>>> From: Jakob Meng <[email protected]> >>>> >>>> In a scenario where OVN does load balancing and then SNAT with a OVS >>>> userspace datapath [0], the recirc_depth may be greater than 6. In >>>> that case, ovs-vswitchd might drop packets and raise warnings: >>>> >>>> dpif_netdev|WARN|Packet dropped. Max recirculation depth exceeded. >>>> >>>> Increasing MAX_RECIRC_DEPTH to 8 solves this issue. >>>> >>>> [0] >>>> https://github.com/ovn-org/ovn/blob/dd5cd73e3df1bfb1a215cb45d1e2e03eff1d049a/tests/system-ovn-kmod.at#L740 >>>> >>>> Reported-at: https://issues.redhat.com/browse/FDP-251 >>>> Signed-off-by: Jakob Meng <[email protected]> >>> Hi Jakob, >>> >>> I'm unsure what the considerations were when setting this limit, >>> but I do note that it was increased once before, from 5 to 6, >>> for an OVN use-case [1]. So this approach seems reasonable to me. >>> >>> Acked-by: Simon Horman <[email protected]> >>> >>> [1] dpif-netdev: Set MAX_RECIRC_DEPTH to 6. >>> https://github.com/openvswitch/ovs/commit/3f9d3836d63a >>> >> >> Hi Ilya, >> can we include this patch in 3.3, please? >> >> It is required for more complex setups like OKD/OpenShift with userspace >> datapaths. > > In the hope of moving this forwards: > > My feeling is that while on the one hand this is a wack-a-mole approach it > does address a real problem in a well understood way, thus moving > things in a positive direction. > > As for downside, there is a risk that this will blow the stack anyway > or somehow cause resource exhaustion that didn't occur before. I didn't > exercise the patch. But I do suspect that risk is minimal. And if it > surfaces we will have to search for a better solution. > > But we don't have a better solution at this time - or at least I don't. > So, other than what I assume is a small risk of regression, do we really > lose anything by moving forward with this simple change at this time?
I think, it's fine for now. The extra 2 recirculations are very unlikely to blow up the stack, especially since the default config is to have 2 MB of pre-allocated and mlocked stack. So, applied for now. Also applied to 3.3 as I don't think this change carries any risk at this time and it will make life of OVN developers/users much easier. But we still need to think of a better way of solving this issue for the future. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
