From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stephen@networkplumber.org> Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by dpdk.org (Postfix) with ESMTP id B1433B639 for <dev@dpdk.org>; Mon, 16 Feb 2015 21:47:14 +0100 (CET) Received: by mail-qa0-f50.google.com with SMTP id f12so23697965qad.9 for <dev@dpdk.org>; Mon, 16 Feb 2015 12:47:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=L4IBQqFDMH0d12q5zsdh/toE8xAsuf2s2BAEIImwh2A=; b=eKeZviivW56xcppRrT+npNLeSKd+PMUI3325yXqH4PHkv6/ZN7tJOlimrbwxYqjptF YNXrQN2f5TPvoAS+zoix2wBw3z0G6liJC38sH2L06zXdYCLO32nIyyz5XEVL+oKNLGJc KrXyzKgTTAyC/IljdZJHNYEvHlSfiStCUyoYKgZHohwMQxmLr+2q6G/CFQ64pR7LywlW fOf6MyRWc4RsgW48EWsP1kmgX5wTWXnI1JkYvW34BXzFgaklXK+2kHyumV9mEHgWbIkJ E9pOsDj+rqjAzV8JnJ/OaDV3ZPPEGg+wqpMkmrTNFDkxppRsodkaG2UQN26A4Bl15J/i C0iQ== X-Gm-Message-State: ALoCoQnd58GMekgS7tiz+7k4Z841DuCEy0LKmzrtd6S2F+/a1xfeMlnA1jaRsqCqXVvvs1ehVbhD X-Received: by 10.140.84.20 with SMTP id k20mr49953qgd.45.1424119634135; Mon, 16 Feb 2015 12:47:14 -0800 (PST) Received: from uryu.home.lan ([67.210.173.2]) by mx.google.com with ESMTPSA id d32sm9025205qga.12.2015.02.16.12.47.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 12:47:14 -0800 (PST) Date: Mon, 16 Feb 2015 15:47:10 -0500 From: Stephen Hemminger <stephen@networkplumber.org> To: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> Message-ID: <20150216154710.42bd6fe9@uryu.home.lan> In-Reply-To: <1424102913-18944-1-git-send-email-sergio.gonzalez.monroy@intel.com> References: <1424102913-18944-1-git-send-email-sergio.gonzalez.monroy@intel.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/2] Removal of RTE_MBUF_REFCNT 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: Mon, 16 Feb 2015 20:47:14 -0000 On Mon, 16 Feb 2015 16:08:31 +0000 Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote: > This patch tries to remove the RTE_MBUF_REFCNT config options and dependencies > by introducing a new mbuf flag IND_ATTACHED_MBUF that would indicate when the mbuf > is an indirect attached mbuf, to differentiate between indirect mbufs and mbufs > with external memory buffers (ie. vhost zero copy). > > Previous discussion: > http://dpdk.org/ml/archives/dev/2014-October/007127.html > > Currently for mbufs with refcnt, we cannot free mbufs with external memory > buffers (ie. vhost zero copy), as they are recognized as indirect > attached mbufs and therefore we free the direct mbuf it points to, > resulting in an error in the case of external memory buffers. > > We solve the issue by introducing the IND_ATTACHED_MBUF flag, which indicates > that the mbuf is an indirect attached mbuf pointing to another mbuf. > When we free an mbuf, we only free the direct mbuf if the flag is set. > Freeing an mbuf with external buffer is the same as freeing a non attached mbuf. > The flag is set during attach and clear on detach. > > So in the case of vhost zero copy where we have mbufs with external > buffers, by default we just free the mbuf and it is up to the user to deal with > the external buffer. > > Sergio Gonzalez Monroy (2): > mbuf: Introduce IND_ATTACHED_MBUF flag > Remove RTE_MBUF_REFCNT references > > app/test/test_link_bonding.c | 15 ----------- > app/test/test_mbuf.c | 17 +++---------- > config/common_bsdapp | 1 - > config/common_linuxapp | 1 - > examples/Makefile | 4 +-- > examples/ip_fragmentation/Makefile | 4 --- > examples/ip_pipeline/Makefile | 3 --- > examples/ip_pipeline/main.c | 5 ---- > examples/ipv4_multicast/Makefile | 4 --- > examples/vhost/main.c | 19 +++----------- > lib/librte_ip_frag/Makefile | 4 --- > lib/librte_ip_frag/rte_ip_frag.h | 4 --- > lib/librte_mbuf/rte_mbuf.c | 2 -- > lib/librte_mbuf/rte_mbuf.h | 45 +++++++-------------------------- > lib/librte_pmd_bond/Makefile | 4 --- > lib/librte_pmd_bond/rte_eth_bond.h | 2 -- > lib/librte_pmd_bond/rte_eth_bond_args.c | 2 -- > lib/librte_pmd_bond/rte_eth_bond_pmd.c | 10 -------- > lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 8 ------ > lib/librte_port/Makefile | 4 --- > 20 files changed, 19 insertions(+), 139 deletions(-) > What about supporting a clone operation instead of and in addition to attach? The refcnt is also useful when there are two paths for a packet (going into mulitple rings).