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 4B87BB420 for ; Wed, 18 Feb 2015 10:52:54 +0100 (CET) Received: by mail-wi0-f178.google.com with SMTP id em10so839584wid.5 for ; Wed, 18 Feb 2015 01:52:54 -0800 (PST) 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=lX55A3MJtd+KFMv8/1XbFTLdUqy2U0OPXpNL/8g8eGQ=; b=F4t/Q9IRmHU75c+hfcX25kolESP4jXi0XX8+mEI5RbkQFC+5QvXi8WLRxg2Qp2vj2h dBls07YLnzOismBebuIWySnmcPLh4TB/cpa02n05bcBaqX0pAknKf2Ygm7Yd29dxr84c q3Q5XdWI4dJOMXdeizZFoYfvJtq8SUC2mJMqQ3acYFyzu1Oe2DPr1mHVNj0N92WjgCym w/0sGlSVkXQKGK5rZCxgWtrjPdgOtVxCjZlcpbdKe9k8R5Lo/0LWc0ZFwZpCjC1i4jU0 D9hjLgqbPrdHMm34YpBhbYQsKFfao8LK6hnDwtMq3jvYOXoRWseb2T94pccAJzPwKWs6 2AeA== X-Gm-Message-State: ALoCoQkgv/fZOpevOS6YB3j89IZlTog1dmwhayhxw8EuLE4U941DSqn55VFyib2AdoujXZHQll4+ X-Received: by 10.180.103.40 with SMTP id ft8mr3323096wib.68.1424253171431; Wed, 18 Feb 2015 01:52:51 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id y14sm18580364wjr.39.2015.02.18.01.52.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 01:52:50 -0800 (PST) Message-ID: <54E460F4.3040006@6wind.com> Date: Wed, 18 Feb 2015 10:52:52 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Bruce Richardson References: <1424102913-18944-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1424102913-18944-3-git-send-email-sergio.gonzalez.monroy@intel.com> <54E45888.7070603@6wind.com> <20150218093548.GA14884@bricha3-MOBL3> In-Reply-To: <20150218093548.GA14884@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 2/2] Remove RTE_MBUF_REFCNT references 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: Wed, 18 Feb 2015 09:52:54 -0000 Hi Bruce, On 02/18/2015 10:35 AM, Bruce Richardson wrote: > On Wed, Feb 18, 2015 at 10:16:56AM +0100, Olivier MATZ wrote: >> Hi Sergio, >> >> On 02/16/2015 05:08 PM, Sergio Gonzalez Monroy wrote: >>> This patch removes all references to RTE_MBUF_REFCNT, setting the refcnt >>> field in the mbuf struct permanently. >>> >>> Signed-off-by: Sergio Gonzalez Monroy >> >> I think removing the refcount compile option goes in the right >> direction. However, activating the refcount will break the applications >> that reserve a private zone in mbufs. This is due to the macros >> RTE_MBUF_TO_BADDR() and RTE_MBUF_FROM_BADDR() that suppose that >> the beginning of the mbuf is 128 bytes (sizeof mbuf) before the >> data buffer. >> > > While I understand how the macros make certain assumptions, how does activating > the refcnt specifically lead to the problems you describe? Could you explain > that part in a bit more detail? Indeed, you are right, removing the refcount option does not break the applications if they do not use it. So there is probably no need to fix that problem in this patch series. However we should consider this problem as the refcount (which can not be deactivated now) is not compatible with the private mbuf data. By the way, once we are on this, shouldn't we consider removing the RTE_MBUF_REFCNT_ATOMIC compile option? Regards, Olivier > > Thanks, > /Bruce > >> For RTE_MBUF_TO_BADDR(), it's relatively easy to replace it. The >> mbuf pool could store the size of the private size like it's done >> for mbp_priv->mbuf_data_room_size. Using rte_mempool_from_obj(m) >> or m->pool, we can retrieve the mbuf pool and this value, then >> compute the buffer address. >> >> For RTE_MBUF_FROM_BADDR(), it's more complex. We could ensure that >> a backpointer to the mbuf is always located before the data buffer, >> but it looks difficult to do. >> >> Another idea would be to add a field in indirect mbufs that stores >> the pointer to the "parent" mbuf. >> >> Regards, >> Olivier >>