On Mon, May 17, 2021 at 08:27:12PM +0200, Martin Pieuchot wrote:
> On 17/05/21(Mon) 19:52, Alexandr Nedvedicky wrote:
> > [...]
> > I don't mind to trade pf_lock and pf_state_lock for mutexes, however
> > I see such step is kind of 'NO-OP'. We do have sufficient measure
> > currently, which is: keep NET_LOCK() as is. May be I'm not seeing
> > your idea/plan behind changing pf's rw-locks to mutexes. If you feel
> > there is a benefit to go that way, then let's do it, but I'd like
> > to understand where we will be going/what to expect.
>
> I've no idea or plan. I'm just pointing out that using rwlocks, for the
> moment, add extra work. If it's easy to use mutexes then you might want
> to start with that. The whole network processing path assumes it runs
> without sleeping. I've no idea what can happen when this assumption
> will be broken.
>
I see. I keep forgetting about local bound traffic, which is
far more complex than forwarding scenario.
> I'm well aware that using a single big pf lock is not the best for
> performances, but maybe it's easier to do baby steps.
>
> That said, I don't want to stop or discourage anyone. If you're
> confident enough that rwlocks are the way to go, then please, go
> ahead.
>
I think we can keep mutexes as a kind of fallback plan if we decide
to commit bluhm's diff.
thanks and
regards
sashan
