On Tue, May 10, 2022 at 09:37:12PM +0200, Hrvoje Popovski wrote: > On 9.5.2022. 22:04, Alexander Bluhm wrote: > > Can some veb or smr hacker explain how this is supposed to work? > > > > Sleeping in pf is also not ideal as it is in the hot path and slows > > down packets. But that is not easy to fix as we have to refactor > > the memory allocations before converting pf lock to a mutex. sashan@ > > is working on that. > > > Hi, > > isn't that similar or same panic that was talked about in "parallel > forwarding vs. bridges" mail thread on tech@ started by sashan@ > > https://www.mail-archive.com/tech@openbsd.org/msg64040.html
Yes. It is similar. I have read the whole mail thread and the final fix got commited. But it looks incomplete, pf is still sleeping. Hrvoje, can you run the tests again that triggered the panics a year ago? Sasha, I still think the way to go is mutex for pf locks. I don't see a performance impact. Without it, we can run network only on a single CPU anyway. And with sleeping locks you have to schedule in the hot packet path. Our schedueler was never build for that. At genua we started with mutex, made it fine grained, and converted to rcu later. bluhm
