> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, 8 November 2023 17.51
>
> On Tue, 7 Nov 2023 18:38:32 +0100
> Morten Brørup wrote:
>
> > > If user decides to use a thread unsafe mempool, wouldn't it break
> in
> > > every PMD as well.
> >
> > Yes, except if the a
On Tue, 7 Nov 2023 18:38:32 +0100
Morten Brørup wrote:
> > If user decides to use a thread unsafe mempool, wouldn't it break in
> > every PMD as well.
>
> Yes, except if the application only uses one thread for packet processing.
> Then thread safety is not necessary.
>
If application only
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, 7 November 2023 17.41
>
> On Tue, 7 Nov 2023 08:22:37 +0100
> Morten Brørup wrote:
>
> > > >
> > > > Or are you saying that if they want to use dumpcap, they must
> choose
> > > a thread safe pool type for their appli
On Tue, 7 Nov 2023 08:22:37 +0100
Morten Brørup wrote:
> > > 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 d
On Tue, 7 Nov 2023 08:22:37 +0100
Morten Brørup wrote:
> > >
> > > 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 natur
> 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 wrote:
>
> > > > And I guess there might be other use cases than this one, where a
> > > thread-safe mempool driver is required. So adding a
On Mon, 6 Nov 2023 22:50:50 +0100
Morten Brørup 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.
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, 6 November 2023 20.24
>
> On Mon, 2 Oct 2023 10:42:53 +0200
> Morten Brørup wrote:
>
> > > Switching to rte_pktmbuf_pool_create() still leaves the user with
> the
> > > possibility to shoot himself in the foot (I was t
On Mon, 2 Oct 2023 09:33:50 +0200
David Marchand wrote:
> Switching to rte_pktmbuf_pool_create() still leaves the user with the
> possibility to shoot himself in the foot (I was thinking of setting
> some --mbuf-pool-ops-name EAL option).
>
> This application has explicit requirements in terms o
On Mon, 2 Oct 2023 10:42:53 +0200
Morten Brørup wrote:
> > Switching to rte_pktmbuf_pool_create() still leaves the user with the
> > possibility to shoot himself in the foot (I was thinking of setting
> > some --mbuf-pool-ops-name EAL option).
> >
> > This application has explicit requirements i
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Monday, 2 October 2023 09.34
>
> On Fri, Aug 4, 2023 at 6:16 PM Stephen Hemminger
> wrote:
> >
> > The ring used to store mbufs needs to be multiple producer,
> > multiple consumer because multiple queues might on multiple
> > core
On Fri, Aug 4, 2023 at 6:16 PM Stephen Hemminger
wrote:
>
> The ring used to store mbufs needs to be multiple producer,
> multiple consumer because multiple queues might on multiple
> cores might be allocating and same time (consume) and in
> case of ring full, the mbufs will be returned (multiple
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Friday, 4 August 2023 18.16
>
> The ring used to store mbufs needs to be multiple producer,
> multiple consumer because multiple queues might on multiple
> cores might be allocating and same time (consume) and in
> case of ring
13 matches
Mail list logo
