John Hurley <john.hur...@netronome.com> wrote: > On Thu, Jun 6, 2019 at 1:58 PM Florian Westphal <f...@strlen.de> wrote: > > I dislike this, why can't we just use a pcpu counter? > > > > The only problem is with recursion/nesting; whenever we > > hit something that queues the skb for later we're safe. > > > > Hi Florian, > The per cpu counter (initial proposal) should protect against > recursion through loops and the potential stack overflows. > It will not protect against a packet infinitely looping through a poor > configuration if (as you say) the packet is queued at some point and > the cpu counter reset.
Yes, it won't help, but thats not harmful, such cycle will be broken/resolved as soon as the configuration is fixed. > The per skb tracking seems to accommodate both issues. Yes, but I do not see the 'looping with queueing' as a problem, it can also occur for different reasons. > Do you see the how the cpu counter could stop infinite loops in the > case of queuing? No, but I don't think it has to. > Or perhaps these are 2 different issues and should be treated differently? The recursion is a problem, so, yes, I think these are different issues. > > We can't catch loops in real (physical) setups either, > > e.g. bridge looping back on itself. > > yes, this is only targeted at 'internal' loops. Right, however, I'm not sure we should bother with those, we can't prevent this (looping packets) from happening for other reasons. I'm sure you can make packets go in circles without tc, e.g. via veth+bridge+netns.
