> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 7 November 2023 03.36 > > On Mon, 6 Nov 2023 22:50:50 +0100 > Morten Brørup <m...@smartsharesystems.com> wrote: > > > > > And I guess there might be other use cases than this one, where a > > > thread-safe mempool driver is required. So adding a generalized > > > function to get the "upgraded" (i.e. thread safe) variant of a > mempool > > > driver would be nice. > > > > </feature creep> > > > > > > If the user overrides the default mbuf pool type, then it will need > to > > > be thread safe for > > > the general case of driver as well (or they are on single cpu). > > > > If they have chosen a thread safe pool type, using the chosen type > will work for dumpcap too. I think we all agree on that. > > > > I'm not sure I understand your single-cpu argument, so let me try to > paraphrase: > > > > If their application only uses one EAL thread, and they have chosen > "ring_sc_sp", dumpcap also work, because mempool accesses are still > single-threaded. Is this correctly understood? > > > > Or are you saying that if they want to use dumpcap, they must choose > a thread safe pool type for their application (regardless if the > application is single-threaded or not)? > > There is no command line of EAL nature in dumpcap. > This is intentional. > QED: overriding default pool type is not going to be a possible
The preferred mbuf pool type can configured in the primary process by EAL params. If so configured, it is stored in a memzone named "mbuf_user_pool_ops". And if it is set there, the secondary process will also use it as its preferred mbuf pool type.
