On Thu, Nov 05, 2020 at 10:35:45AM +0100, Morten Brørup wrote:
> There is a simple alternative for applications with a single mbuf pool to
> avoid accessing m->pool.
>
> We could add a global variable pointing to the single mbuf pool.
>
> It would be NULL by default.
>
> It would be set by rte_
There is a simple alternative for applications with a single mbuf pool to avoid
accessing m->pool.
We could add a global variable pointing to the single mbuf pool.
It would be NULL by default.
It would be set by rte_pktmbuf_pool_create() on first invocation, and reset
back to NULL on following
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Thursday, November 5, 2020 1:26 AM
>
> >
> > Hi,
> >
> > On Tue, Nov 03, 2020 at 04:03:46PM +0100, Morten Brørup wrote:
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Slava
> Ovsiienko
> > > > Sent:
>
> Hi,
>
> On Tue, Nov 03, 2020 at 04:03:46PM +0100, Morten Brørup wrote:
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Slava Ovsiienko
> > > Sent: Tuesday, November 3, 2020 3:03 PM
> > >
> > > Hi, Morten
> > >
> > > > From: Morten Brørup
> > > > Sent: Tuesday, November 3, 2020
Hi,
On Tue, Nov 03, 2020 at 04:03:46PM +0100, Morten Brørup wrote:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Slava Ovsiienko
> > Sent: Tuesday, November 3, 2020 3:03 PM
> >
> > Hi, Morten
> >
> > > From: Morten Brørup
> > > Sent: Tuesday, November 3, 2020 14:10
> > >
> > > > From
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Slava Ovsiienko
> Sent: Tuesday, November 3, 2020 3:03 PM
>
> Hi, Morten
>
> > From: Morten Brørup
> > Sent: Tuesday, November 3, 2020 14:10
> >
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Monday, November 2, 2020 4:
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Tuesday, November 3, 2020 2:50 PM
>
> On Tue, Nov 03, 2020 at 02:46:17PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Tuesday, November 3, 2020 1:26 PM
> > >
> > > On Tu
, Ferruh
> ; david.march...@redhat.com; Richardson, Bruce
> ; olivier.m...@6wind.com; jer...@marvell.com;
> Slava Ovsiienko ; honnappa.nagaraha...@arm.com;
> maxime.coque...@redhat.com; step...@networkplumber.org;
> hemant.agra...@nxp.com; Slava Ovsiienko ; Matan
> Azrad ; Shahaf Shuler
&g
On Tue, Nov 03, 2020 at 02:46:17PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Tuesday, November 3, 2020 1:26 PM
> >
> > On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > > > From: Thomas Monjalon [mailto:tho...@monjalon.net
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Tuesday, November 3, 2020 1:26 PM
>
> On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Monday, November 2, 2020 4:58 PM
> > >
> > > +Cc techboard
On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Monday, November 2, 2020 4:58 PM
> >
> > +Cc techboard
> >
> > We need benchmark numbers in order to take a decision.
> > Please all, prepare some arguments and numbers
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, November 2, 2020 4:58 PM
>
> +Cc techboard
>
> We need benchmark numbers in order to take a decision.
> Please all, prepare some arguments and numbers so we can discuss
> the mbuf layout in the next techboard meeting.
I propose
+Cc techboard
We need benchmark numbers in order to take a decision.
Please all, prepare some arguments and numbers so we can discuss
the mbuf layout in the next techboard meeting.
01/11/2020 21:59, Morten Brørup:
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Sunday, November
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Sunday, November 1, 2020 5:38 PM
>
> 01/11/2020 10:12, Morten Brørup:
> > One thing has always puzzled me:
> > Why do we use 64 bits to indicate which memory pool
> > an mbuf belongs to?
> > The portid only uses 16 bits and an indirectio
01/11/2020 10:12, Morten Brørup:
> One thing has always puzzled me:
> Why do we use 64 bits to indicate which memory pool
> an mbuf belongs to?
> The portid only uses 16 bits and an indirection index.
> Why don't we use the same kind of indirection index for mbuf pools?
I wonder what would be the
That's very interesting food for thoughts.
I hope we will have a good community discussion on this list
during this week to make some decisions.
01/11/2020 10:12, Morten Brørup:
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Saturday, October 31, 2020 9:41 PM
> >
> > 31/10/2020
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Saturday, October 31, 2020 9:41 PM
>
> 31/10/2020 19:20, Morten Brørup:
> > Thomas,
> >
> > Adding my thoughts to the already detailed feedback on this important
> patch...
> >
> > The first cache line is not inherently "hotter" than the
Thanks for the thoughts Morten.
I believe we need benchmarks of different scenarios with different drivers.
31/10/2020 19:20, Morten Brørup:
> Thomas,
>
> Adding my thoughts to the already detailed feedback on this important patch...
>
> The first cache line is not inherently "hotter" than the
Thomas,
Adding my thoughts to the already detailed feedback on this important patch...
The first cache line is not inherently "hotter" than the second. The hotness
depends on their usage.
The mbuf cacheline1 marker has the following comment:
/* second cache line - fields only used in slow path
19 matches
Mail list logo
