From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
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 <dev@dpdk.org>; Tue, 13 May 2014 15:29:14 +0200 (CEST)
Received: by mail-wi0-f178.google.com with SMTP id hm4so599460wib.5
 for <dev@dpdk.org>; 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 <multiple recipients>
 (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 <olivier.matz@6wind.com>
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 <stephen@networkplumber.org>
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" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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