Hi Dave,
> From: Dave Barach (dbarach) [mailto:dbarach at cisco.com]
> Sent: Wednesday, June 17, 2015 4:46 PM
> To: Venkatesan, Venky; Richardson, Bruce; olivier.matz at 6wind.com; Ananyev,
> Konstantin
> Cc: Damjan Marion (damarion)
> Subject: RE: [dpdk-dev] rte_mbuf.nex
2015-06-17 14:23, Damjan Marion:
>
> > On 17 Jun 2015, at 16:06, Bruce Richardson
> > wrote:
> >
> > On Wed, Jun 17, 2015 at 01:55:57PM +, Damjan Marion (damarion) wrote:
> >>
> >>> On 15 Jun 2015, at 16:12, Bruce Richardson >>> intel.com> wrote:
> >>>
> >>> The next pointers always star
2015-06-17 13:55, Damjan Marion:
>
> > On 15 Jun 2015, at 16:12, Bruce Richardson
> > wrote:
> >
> > The next pointers always start out as NULL when the mbuf pool is created.
> > The
> > only time it is set to non-NULL is when we have chained mbufs. If we never
> > have
> > any chained mbufs,
On Wed, Jun 17, 2015 at 01:55:57PM +, Damjan Marion (damarion) wrote:
>
> > On 15 Jun 2015, at 16:12, Bruce Richardson
> > wrote:
> >
> > The next pointers always start out as NULL when the mbuf pool is created.
> > The
> > only time it is set to non-NULL is when we have chained mbufs. If
> On 17 Jun 2015, at 16:06, Bruce Richardson
> wrote:
>
> On Wed, Jun 17, 2015 at 01:55:57PM +, Damjan Marion (damarion) wrote:
>>
>>> On 15 Jun 2015, at 16:12, Bruce Richardson
>>> wrote:
>>>
>>> The next pointers always start out as NULL when the mbuf pool is created.
>>> The
>>> onl
> On 15 Jun 2015, at 16:12, Bruce Richardson
> wrote:
>
> The next pointers always start out as NULL when the mbuf pool is created. The
> only time it is set to non-NULL is when we have chained mbufs. If we never
> have
> any chained mbufs, we never need to touch the next field, or even read i
ne 15, 2015 5:23 PM
> > > To: Ananyev, Konstantin
> > > Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> > >
> > > On Mon, Jun 15, 2015 at 05:10:44PM +0100, Ananyev, Konstantin wrote
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, June 15, 2015 5:23 PM
> To: Ananyev, Konstantin
> Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>
> On Mon, Jun 15, 2015 at 0
damarion)
> > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> >
> > On Mon, Jun 15, 2015 at 04:59:55PM +0100, Ananyev, Konstantin wrote:
> > >
> > >
> > >
> > > As I can see, vector TX is the only one that calls
> > > __rte_pktm
at dpdk.org; Damjan Marion (damarion)
>> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>>
>>
>>
>> On 06/15/2015 04:12 PM, Bruce Richardson wrote:
>>> On Mon, Jun 15, 2015 at 04:05:05PM +0200, Olivier MATZ wrote:
>>>> Hi,
>>>&g
On Mon, Jun 15, 2015 at 04:59:55PM +0100, Ananyev, Konstantin wrote:
>
>
>
> As I can see, vector TX is the only one that calls
> __rte_pktmbuf_prefree_seg() directly.
> All others use rte_pktmbuf_free_seg(), that does ' m->next = NULL' anyway.
> For vector TX - yes, need to verify that it woul
t; >
> > > >> -Original Message-
> > > >> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> > > >> Sent: Monday, June 15, 2015 3:31 PM
> > > >> To: Richardson, Bruce
> > > >> Cc: Ananyev, Konstantin; dev at d
[mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
>>>> Sent: Monday, June 15, 2015 2:44 PM
>>>> To: Olivier MATZ
>>>> Cc: dev at dpdk.org; Damjan Marion (damarion)
>>>> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>>>
onday, June 15, 2015 3:31 PM
> >> To: Richardson, Bruce
> >> Cc: Ananyev, Konstantin; dev at dpdk.org; Damjan Marion (damarion)
> >> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> >>
> >>
> >>
> >> On 06/15/2015 04:12 PM, Bruce Ri
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, June 15, 2015 5:02 PM
> To: Ananyev, Konstantin
> Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>
> On Mon, Jun 15, 2015 at 0
ion (damarion)
>> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>>
>> On Mon, Jun 15, 2015 at 03:20:22PM +0200, Olivier MATZ wrote:
>>> Hi Damjan,
>>>
>>> On 06/10/2015 11:47 PM, Damjan Marion (damarion) wrote:
>>>>
>>>>
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, June 15, 2015 4:40 PM
> To: Ananyev, Konstantin; #
> Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>
> On Mon, Jun 15, 2015 at 0
:
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> >>>> Sent: Monday, June 15, 2015 2:44 PM
> >>>> To: Olivier MATZ
> >>>> C
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, June 15, 2015 4:24 PM
> To: Olivier MATZ
> Cc: Ananyev, Konstantin; dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>
> On Mon, Jun 15, 2015 at 0
Hi Damjan,
On 06/10/2015 11:47 PM, Damjan Marion (damarion) wrote:
>
> Hi,
>
> We noticed 7% performance improvement by simply moving rte_mbuf.next field to
> the 1st cache line.
>
> Currently, it falls under /* second cache line - fields only used in slow
> path or on TX */
> but it is actua
> Sent: Monday, June 15, 2015 2:44 PM
> >> To: Olivier MATZ
> >> Cc: dev at dpdk.org; Damjan Marion (damarion)
> >> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> >>
> >> On Mon, Jun 15, 2015 at 03:20:22PM +0200, Olivier MATZ wrote:
> >
Hi Olivier,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, June 15, 2015 3:31 PM
> To: Richardson, Bruce
> Cc: Ananyev, Konstantin; dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.nex
On Mon, Jun 15, 2015 at 03:20:22PM +0200, Olivier MATZ wrote:
> Hi Damjan,
>
> On 06/10/2015 11:47 PM, Damjan Marion (damarion) wrote:
> >
> > Hi,
> >
> > We noticed 7% performance improvement by simply moving rte_mbuf.next field
> > to the 1st cache line.
> >
> > Currently, it falls under /*
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Monday, June 15, 2015 2:44 PM
> To: Olivier MATZ
> Cc: dev at dpdk.org; Damjan Marion (damarion)
> Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
>
>
gt; > Sent: Monday, June 15, 2015 5:02 PM
> > > > To: Ananyev, Konstantin
> > > > Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> > > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> > > >
> > > > On Mon, Jun 15, 20
Hi,
We noticed 7% performance improvement by simply moving rte_mbuf.next field to
the 1st cache line.
Currently, it falls under /* second cache line - fields only used in slow path
or on TX */
but it is actually used at several places in rx fast path. (e.g.:
i40e_rx_alloc_bufs() is setting th
26 matches
Mail list logo
