From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id CDBC16C9B for ; Tue, 17 May 2016 16:19:38 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id n129so142581832wmn.1 for ; Tue, 17 May 2016 07:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=heXjt/5KrlXY7Jh+mZAIocpWx4og2Yi+bRtK3QDiOSI=; b=MSjZjhXfXYxuQkSaMIZh4CuKdYv+eAkwt+TxdDyjlc5LUMaoYiYxjQoKz5YhSm6J0M wUmSKqE/ge/If8NhaQt76BaGRLKORScpCI+afrrZM5KfVoPbKNesihM+DsR2dXVWoGhD WIQbxGODB+0XDxrrwIikgmOdjctUW6h7o49Kb3MPC0xLKpp5dN8/cstumu1iIvsXL1rW yAj278yhO2GkmS8yMDKuNJsvXBQMK3eNlBpnHTlJzg9pehFbdPdJIuJjcDHoNBhawM0S DpS29XB4XHtCZpO1MIjsSu/5UA5wFi2tlheX2G63ccpdw3NaDOn12hUdkcXGVitfqHAZ rY8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=heXjt/5KrlXY7Jh+mZAIocpWx4og2Yi+bRtK3QDiOSI=; b=LOdzLNlOcKt2rZZoQR5OJcuLzk/FAhfA+pYKCBLowR067JyWZQgm1i0JdLR8qCMVu1 7wy8RBTRTAwnXwaX6t9jnI+y7/CPIdP7gglPR/hNU+rG4PLWN7ABfcDh5JgGid7UMKMu +nMh4whmlHsbFJOGsw/BFCSnWXy0frINSuzIGdYtxU90QEvx86234XfW9CfFnf2H3Hcj i5E4UqYb3usoNpAEKZBRxUASxgt6oYhnqtr5JU6eeVs25FVivvFUAs1bFLzYos755gfV 4yP8SbHvHTwN7D6DDoU6nI6jduFr2Xb5e+/OrZSDAJENbWUA2fVTWciOaciGPF7EmexG GazQ== X-Gm-Message-State: AOPr4FVPdD/DEjV6YGzXoFbOjXGX6qBeojXRg0O6lTTlp1kYg0sJUAsrrquJYsVUOwqHWa3W X-Received: by 10.28.157.143 with SMTP id g137mr1815512wme.29.1463494778596; Tue, 17 May 2016 07:19:38 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id v9sm3408502wjt.1.2016.05.17.07.19.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 07:19:37 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: dev@dpdk.org, Hiroyuki Mikita , olivier.matz@6wind.com Date: Tue, 17 May 2016 16:19:17 +0200 Message-ID: <3377984.UT2r9Befy8@xps13> User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB97725836B518CE@irsmsx105.ger.corp.intel.com> References: <1463327436-6863-1-git-send-email-h.mikita89@gmail.com> <1709340.0fJkCxgyM5@xps13> <2601191342CEEE43887BDE71AB97725836B518CE@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] mbuf: decrease refcnt when detaching 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, 17 May 2016 14:19:39 -0000 2016-05-17 13:44, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-05-17 12:59, Ananyev, Konstantin: > > > > > The rte_pktmbuf_detach() function should decrease refcnt on a direct > > > > > buffer. > > > > > > > > As you have noticed, "whenever the indirect buffer is detached, > > > > the reference counter on the direct buffer is decremented." > > > > So the current behaviour of rte_pktmbuf_detach() is buggy. > > > > Why not fix it without renaming? > > > > If you consider this behavioral bug is part of the API, we > > > > can fix it in a new function unattach and deprecate detach. > > > > But Konstantin, why do you want to keep a restore function? > > > > What is the need? > > > > > > I think it might be a useful functionality in some situations: > > > some users can attach/detach to external memory buffers (no mbufs) > > > and similar functionality is required. > > > > Attach to external memory buffer (raw buffer) is not currently supported. > > > > > Let say right now examples/vhost/main.c has its own pktmbuf_detach_zcp() > > > > You should look at the commit http://dpdk.org/commit/68363d85 > > "examples/vhost: remove the non-working zero copy code" > > > > > which is doing pretty much the same - restore original values, after detaching > > > mbuf from external (virtio) memory buffer. > > > Would be good if we'll use a standard API function here. > > > > You are welcome to implement mbuf attach to raw buffer. > > But it is not a requirement for this fix. > > Hmm, still not sure why we can't keep an existing function? Because it does not do what its name (and doc) suggest. > Obviously it wouldn't cost anything and I still think might be useful. It costs to overcomplicate API for only a half support. If you need the feature "attach to raw", please implement it completely.