On Tue, Feb 6, 2024 at 3:47 PM Eelco Chaudron <[email protected]> wrote: > On 6 Feb 2024, at 15:17, David Marchand wrote: > > > 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. > > 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. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
