Hi Venky,
2014-05-13 13:54, Venkatesan, Venky:
> An alternative way to save 6 bytes (without the side effects this change
> has) would be to change the mempool struct * to a uint16_t mempool_id. That
> limits the changes to a return function, and the performance impact of that
> can be mitigated q
Hi Stephen,
On 05/12/2014 07:13 PM, Stephen Hemminger wrote:
> In cloned mbuf
> rte_pktmbuf_mtod(m, char *) points to the original data.
> RTE_MBUF_TO_BADDR(m) points to buffer in the mbuf which we
> use for metadata (timestamp).
I still don't see the problem. Let's take an example: m2 is a clone
-
From: Neil Horman [mailto:nhor...@tuxdriver.com]
Sent: Monday, May 12, 2014 11:40 AM
To: Venkatesan, Venky
Cc: Olivier MATZ; Thomas Monjalon; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an
offset
On Mon, May 12, 2014 at 04:06:23PM +, Venkatesan, Venky
Hi Stephen,
On 05/12/2014 05:59 PM, Stephen Hemminger wrote:
> There is one case which this case might make problematic.
> Right now it is possible to clone an mbuf and in the cloned mbuf
> use the associated data buffer as private meta data store.
> This is convenient (like skb->cb in Linux) and
Hi Venky,
On 05/12/2014 04:41 PM, Neil Horman wrote:
>> This is a hugely problematic change, and has a pretty large
>> performance impact (because the dependency to compute and access). We
>> debated this for a long time during the early days of DPDK and
>> decided against it. This is also a repea
Hi Olivier,
2014-05-09 16:50, Olivier Matz:
> The mbuf structure already contains a pointer to the beginning of the
> buffer (m->buf_addr). It is not needed to use 8 bytes again to store
> another pointer to the beginning of the data.
>
> Using a 16 bits unsigned integer is enough as we know that
y, May 12, 2014 8:07 AM
To: Neil Horman; Venkatesan, Venky
Cc: Thomas Monjalon; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an
offset
Hi Venky,
On 05/12/2014 04:41 PM, Neil Horman wrote:
>> This is a hugely problematic change, and has a pre
vier.matz at 6wind.com]
> Sent: Monday, May 12, 2014 8:07 AM
> To: Neil Horman; Venkatesan, Venky
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an
> offset
>
> Hi Venky,
>
> On 05/12/2014 04:41 PM, Neil
: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an
offset
Hi Olivier,
2014-05-09 16:50, Olivier Matz:
> The mbuf structure already contains a pointer to the beginning of the
> buffer (m->buf_addr). It is not needed to use 8 bytes again to store
homas Monjalon
> Sent: Monday, May 12, 2014 7:13 AM
> To: Olivier Matz
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an
> offset
>
> Hi Olivier,
>
> 2014-05-09 16:50, Olivier Matz:
> > The mbuf structure already c
On Mon, 12 May 2014 18:13:26 +0200
Olivier MATZ wrote:
> Hi Stephen,
>
> On 05/12/2014 05:59 PM, Stephen Hemminger wrote:
> > There is one case which this case might make problematic.
> > Right now it is possible to clone an mbuf and in the cloned mbuf
> > use the associated data buffer as priva
On Mon, 12 May 2014 17:07:03 +0200
Olivier MATZ wrote:
> Hi Venky,
>
> On 05/12/2014 04:41 PM, Neil Horman wrote:
> >> This is a hugely problematic change, and has a pretty large
> >> performance impact (because the dependency to compute and access). We
> >> debated this for a long time during t
The mbuf structure already contains a pointer to the beginning of the
buffer (m->buf_addr). It is not needed to use 8 bytes again to store
another pointer to the beginning of the data.
Using a 16 bits unsigned integer is enough as we know that a mbuf is
never longer than 64KB. We gain 6 bytes in t
13 matches
Mail list logo
