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/[email protected]/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
