[dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset

[Olivier MATZ]

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
of m1. Before applying the patch series, we have:

- rte_pktmbuf_mtod(m1) points to m1->pkt.data
- RTE_MBUF_TO_BADDR(m1) points to m1->buf_addr
- rte_pktmbuf_mtod(m2) points to m1->pkt.data
- RTE_MBUF_TO_BADDR(m2) points to m2->buf_addr

After the patches:

- rte_pktmbuf_mtod(m1) points to m1->buf_addr + m1->data_off
- RTE_MBUF_TO_BADDR(m1) points to m1->buf_addr
- rte_pktmbuf_mtod(m2) points to m1->buf_addr + m2->data_off
- RTE_MBUF_TO_BADDR(m2) points to m2->buf_addr

I assume this is equivalent, as m2->data_off will have the same value
than m1->data_off. Have you identified a specific test case that fails?
The mbuf autotest is successful, if you think there is something
else to test, it should be added in the test app.

I don't use this feature, but by the way it seems that the macros
RTE_MBUF_TO_BADDR(mb) and RTE_MBUF_FROM_BADDR(ba) won't return
the proper value if the application initializes a mbuf pool
with an object size != sizeof(rte_mbuf). It thought it was something
quite common as it allows the application to add its own info in the
mbuf.

Regards,
Olivier