From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <olivier.matz@6wind.com> Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id CBEFEB470 for <dev@dpdk.org>; Wed, 18 Feb 2015 12:01:28 +0100 (CET) Received: by mail-wg0-f41.google.com with SMTP id b13so437529wgh.0 for <dev@dpdk.org>; Wed, 18 Feb 2015 03:01:28 -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=ut5uGjHBirn+Cct98ud7IHonk3bPGn0jbxQvQtOBZ9o=; b=cIZHUFchgJXgVtU11Gchg0ank+9AeZqQdn4D2K5vBHcAW9kEUMcKbMaIjjgayVvse4 6shwn1uldFeQvRhqJz8ZQJRN+bIPXC9R8r6cqYnaI6zd07VrUXsrzHAYC/fwFOMNLpt4 hrCIHbyIREXrYvE7kmJs5DFG5O58BEXUKBTDrpJRTgUUGjSM2PjTDv/Fuhqyb80PriU2 mDPre8Zq9WSapgcaWmvYgvRDufBMXe3p2Ge8Yk7EWbt/Q31r7iO8NxJa+AQ+SZ68nd5P zg0nmU0WPYfs9iHLhJumgBy+FtqAXlA8dS1kkewK19ckBZxZ985UTucsdMBZtb2WFyiF GWAw== X-Gm-Message-State: ALoCoQlwDpjpTF7cNMbuj4Zhyy6lXfkRI9sJ/lVwabUlAGGj2Vc0HJyLxtcOK93V1Jodof6YS7Iw X-Received: by 10.194.223.5 with SMTP id qq5mr72789224wjc.152.1424257287360; Wed, 18 Feb 2015 03:01:27 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id fo8sm6488214wib.14.2015.02.18.03.01.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 03:01:26 -0800 (PST) Message-ID: <54E47107.3020103@6wind.com> Date: Wed, 18 Feb 2015 12:01:27 +0100 From: Olivier MATZ <olivier.matz@6wind.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com> 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> <2601191342CEEE43887BDE71AB977258213EF5E4@irsmsx105.ger.corp.intel.com> <20150218100003.GA14728@bricha3-MOBL3> <54E46612.7050809@6wind.com> <20150218102253.GA6804@bricha3-MOBL3> <54E46A8C.9010105@6wind.com> <2601191342CEEE43887BDE71AB977258213EF67E@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213EF67E@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" <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 <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: Wed, 18 Feb 2015 11:01:29 -0000 Hi Konstantin, On 02/18/2015 11:47 AM, Ananyev, Konstantin wrote: >>> How was this managed before, since refcnt field seems to be necessary in order >>> to effectively manage indirect mbufs? Is this just the case that this is something >>> that never worked and that needs to be solved, or is it something that was >>> working that this patch will now break? >> >> This is something that never worked before: refcounts are not compatible >> with reserving private data in mbufs. This patch does not change the >> issue, it is still there. >> >> Before the patch, an application that wanted to reserve a private >> data could disable refcounts at compile-time. >> After the patch, the solution is just to avoid using refcounts. > > I'd say avoid using mbuf_attach/detach. > refcnt itself has nothing to do with that. > I finally understood what you are talking about ... > About private data - I suppose it is a matter of another patch. > I still think it would be better to reserve private data space before mbuf, not after > (at mbuf pool initialisation time). > Then *BADDR* macros could be unaffected. Indeed that could be a good idea. Regards, Olivier