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