From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH RFC 06/11] mbuf: replace data pointer by an offset Date: Tue, 13 May 2014 15:29:18 +0200 Message-ID: <53721E2E.9090204@6wind.com> References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-7-git-send-email-olivier.matz@6wind.com> <3144526.CGFdr4BbI8@xps13> <1FD9B82B8BF2CF418D9A1000154491D9740A92B8@ORSMSX102.amr.corp.intel.com> <20140512144108.GB21298@hmsreliant.think-freely.org> <5370E397.7000706@6wind.com> <20140512085924.20a29cad@nehalam.linuxnetplumber.net> <5370F326.8070206@6wind.com> <20140512101316.0c0d2824@nehalam.linuxnetplumber.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Stephen Hemminger Return-path: In-Reply-To: <20140512101316.0c0d2824-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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