On Tue, Feb 6, 2024 at 2:31 PM Eelco Chaudron <[email protected]> wrote:
>
> Avoid unnecessary thread creation as no upcalls are generated,
> resulting in idle threads waiting for process termination.
>
> This optimization significantly reduces memory usage, cutting it
> by half on a 128 CPU/thread system during testing, with the number
> of threads reduced from 95 to 0.
>
> Signed-off-by: Eelco Chaudron <[email protected]>
I find it weird that the dpif layer reports an information on how the
ofproto-dpif layer behaves.
The handler threads are something ofproto-dpif is responsible for.
The upcall receiving loop is something the ofproto-dpif owns.
Why should the dpif layer tells how many handlers are needed?
I would have seen a different change, where the dpif layer exports a
capability, like dpif_can_recv() { return !!dpif->dpif_class->recv; }.
ofproto-dpif would then deduce there is no handler to start at all.
--
David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
