Hello, 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. >
rw-lock in pf is indeed a next step. The first step is to move memory allocations done by ioctl(2) out of network path. same goes to copyin()/copyout(). I'm currently looking at art tables. I theory it should be possible to replace current radix tables with art tables. If I understand things right, this would also solve locking on update. > > 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 > this is very similar to panics you've found. However this time packets sneak to sleep path via call to veb_span(). I agree the fix looks odd. May be another way around it would be to add a task to every veb switch. The task will dispatch packets to slow path. regards sashan