On Mon, May 16, 2022 at 05:06:28PM +0200, Claudio Jeker wrote:
> > In veb configuration we are holding the netlock and sleep in
> > smr_barrier() and refcnt_finalize().  An additional sleep in malloc()
> > is fine here.
> 
> Are you sure about this? smr_barrier() on busy systems with many cpus can
> take 100ms and more. Isn't all processing stopped during that time (IIRC
> the code uses the write exclusive netlock).

Interface ioctls are called with netlock.  veb_ioctl() calls
veb_add_port() and veb_del_port() which call smr_barrier().

I did not notice 100ms network sleep during ifconfig.  I would not
consider it an urgent problem.  If you optimize for one thing, you
pay the price somewhere else.

> Sleeping with a global rwlock held is not a good design.

And here we are back to the net lock design discussion we had with
mpi@ years ago.  More important is progress.  We should not spend
too much time on design discussion.  Better solve problems.

My plan is, in more or less this order:
- use exclusive netlock for configuration
- use shared netlock for parts that are MP safe
- kernel lock together with net lock allows quick fixes
  to make progress without making everything MP perfect
- replace kernel lock with mutex
- use something smarter than mutex to make things fast

Others have other plans, so we have different maturity of MP support
in the kernel.

bluhm

Reply via email to