On 10/19/22 15:48, Mike Pattrick wrote: > On Wed, Oct 19, 2022 at 9:30 AM Flavio Leitner <[email protected]> wrote: >> >> >> Hi Mike, >> >> Thanks for the patch. >> >> Does this patch need to change this line too? >> https://github.com/openvswitch/ovs/blob/31db0e043119cf597d720d94f70ec19cf5b8b7d4/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in#L18 >> >> >> Wouldn't it be better to have a config option that we >> can change at runtime? Or perhaps leave it to use the >> system's default unless configured to cap the amount? > > What I'm worried about here is if OVN is used and a few other things > like dnat/snat, the resulting openflow rules can cause a segfault with > the system default 2MB stack. The stack conditions aren't really > detectable during runtime so increasing the default seemed reasonable > to me. It also doesn't seem trivial to me to determine if any given > set of OpenFlow rules will or won't cause an explosion in stack usage.
Hi, Mike. I was thinking in the past about a bit different approach to the problem. I have a guess that most of the stack usage is coming from 'struct flow' and some of the stab[] memory allocations on the stack and these are huge. Can easily take a few KB of space each. So, I wonder, if you have a coredump or a reproducer, maybe you could confirm or disprove that theory? That would be very helpful If the theory will turn out to be true, the solution might be to move all that to dynamically allocated memory instead of trying to guess the sufficient upper limit for a stack size. (Moving these to a heap might be a good idea even if they are not a root cause of the current problem, I think.) What do you think? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
