On 6 Feb 2024, at 15:50, David Marchand wrote:
> On Tue, Feb 6, 2024 at 3:47 PM Eelco Chaudron <echau...@redhat.com> wrote:
>> 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.
>
> The fact that it exists does not convince me on its validity :-).
> I must be missing something.
Well, it makes sense that if your dpif requires a specific number of handlers
other than what ofproto suggests you can override this.
And this is what happens here, ofproto will suggest 90+ threads if we do not
report that we want 0.
I think this is more clean than doing another check for a missing callback and
using that to determine if we need to start threads.
//Eelco
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
