On 6 Feb 2024, at 15:17, David Marchand wrote:
> On Tue, Feb 6, 2024 at 2:31 PM Eelco Chaudron <echau...@redhat.com> 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 <echau...@redhat.com>
>
> 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.
That was my first idea also, but then I found there is already an API call to
the dpif layer where it can tell the user (ofproto in this case) how many
threads it needs to function correctly. Here is the API definition:
369 /* Queries 'dpif' to see if a certain number of handlers are required
by
370 * the implementation.
371 *
372 * If a certain number of handlers are required, returns 'true' and
sets
373 * 'n_handlers' to that number of handler threads.
374 *
375 * If not, returns 'false'.
376 */
377 bool (*number_handlers_required)(struct dpif *dpif, uint32_t
*n_handlers);
I guess the ‘If a certain number of handlers are required, returns 'true’’ part
fits here, as we need 0.
//Eelco
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
