From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id 4B50F3DE for ; Tue, 13 May 2014 15:29:14 +0200 (CEST) Received: by mail-wi0-f178.google.com with SMTP id hm4so599460wib.5 for ; Tue, 13 May 2014 06:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PDBzaVvF6KQ0Stha3c69d8lvqBzqUkOjazoafvtdQfM=; b=Bjmy/3F3FDlNAj+SkgYYw+q3fF3hfOVkGCjt3CFD4q7/JncNwrMKqhEdb/Ljso0QqH HroP0p0GRlaw7jqmhwgwbQSO3m482CN72D2zz2+j7B0mSkUDik+ragC6KrQX3AU7OyaL Kgjtl35baol94YT++OEKYYBz4sunyWIrW7EHrR7TEpEEt/sXj2byk6PRVm0EcTG+LLd3 YmOwecFMsEpYWZcvNmZerN5i5mpCyplfQMMz26OHh9Lh2pX3CU7ItxqNqJxGxnzi4tHf lZ/ZBOmQwW5prvHKjFwQBTEgJCtsefx+AP0Nqgf2bxOlE7XkWkE7e6qdPpxcCC2OtE5E SLpw== X-Gm-Message-State: ALoCoQlbiNJ4ZT4ePXu2Lg16AUTLAZ3jrkVWe1e+iyNkgOv0eSOOfUL2v/5sPkzhPMOot4GcZRGC X-Received: by 10.194.89.40 with SMTP id bl8mr389671wjb.90.1399987761536; Tue, 13 May 2014 06:29:21 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id ej2sm22247367wjd.21.2014.05.13.06.29.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 06:29:20 -0700 (PDT) Message-ID: <53721E2E.9090204@6wind.com> Date: Tue, 13 May 2014 15:29:18 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Stephen Hemminger 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> In-Reply-To: <20140512101316.0c0d2824@nehalam.linuxnetplumber.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 13:29:14 -0000 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