From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.161.196]) by dpdk.org (Postfix) with ESMTP id 55CA668F5 for ; Tue, 17 May 2016 18:13:16 +0200 (CEST) Received: by mail-yw0-f196.google.com with SMTP id u62so2842471ywe.3 for ; Tue, 17 May 2016 09:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WugzhqNsMz+bWbDCF0zRATRsy+Tg2H0yMTGDy4Dprhc=; b=swZAReYYjAAmvawkIAD99jGyOPUTXwo7IRMqVRTOyj0R5hiqt6LgMZC4irT7DOTP73 m8ezJn2cKymSiom07ez5vyW8R1a37xGppDIjY/lLFLigpFqrLt/Oqzfl2iDe+3Ms4HOl YxXxIqk6jksK/anLyE82SmhFbMV+WN0khd96HpKSw8Im6CFCi1FT1JaLmbMNM182O2Rq 7PHPxyJf6vboNrPFzrttUl52cDj0ZMvPI3NvJdFdnszNq1KrEwyTOPjw1x87qpJWCC6/ 8JY7uuof32slQPJohEAXUR8kW5T6fsTvlUc4gy5AIZwrJX6KB++TLeCtC5tWosba5tM+ oEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WugzhqNsMz+bWbDCF0zRATRsy+Tg2H0yMTGDy4Dprhc=; b=UwtMbxiKIkA5cZjS407UM6nVhEO9zN/TOhEq7DWdaHNt20F9rYbI5/tMTuWGtxFWpg u8ds3DTHLZtb+Y0l83ZB2SkQcVbO0fsBY3y/bZ471Z3RPePQgjYEgUZgqHYcWPF4La8P H1f7O14cJUOSj4wDxyt06FvjaLw8QX89GMk51RNEa/0luvZA27IPBiCGzLzCeXHTqhUF OwEWnRahntJWaacP10PoQkkmvAIUQMcbv/deW62ltkvVYaVp4DkqMRQhFZON7pfMRRLT L1XFqlDsGiNYCHP7Gf8FHf/5v6jB0Xv7LAl7n9DTGhAewkCkm/DjljXut6v6GkAor6IF bL6Q== X-Gm-Message-State: AOPr4FV22SX9KlR7PTR8bnSq0Lst3HvIuR/ZAH2pTZSYZwHU/tYvLIziOUepPig6eg/gxFvQ3UxGLAJPrblGDg== X-Received: by 10.129.161.19 with SMTP id y19mr1080508ywg.119.1463501595774; Tue, 17 May 2016 09:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.214 with HTTP; Tue, 17 May 2016 09:12:56 -0700 (PDT) In-Reply-To: <2601191342CEEE43887BDE71AB97725836B51936@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> <3377984.UT2r9Befy8@xps13> <2601191342CEEE43887BDE71AB97725836B51936@irsmsx105.ger.corp.intel.com> From: Hiroyuki MIKITA Date: Wed, 18 May 2016 01:12:56 +0900 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "dev@dpdk.org" , "olivier.matz@6wind.com" Content-Type: text/plain; charset=UTF-8 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 16:13:16 -0000 I think this behavior is not part of the API, it is a bug. I agree that detach() frees the direct mbuf when refcnt becomes 0, Konstantin suggests. It is a right behavior of reference counting. Regards, Hiroyuki 2016-05-18 0:45 GMT+09:00 Ananyev, Konstantin : > > >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> Sent: Tuesday, May 17, 2016 3:19 PM >> To: Ananyev, Konstantin >> Cc: dev@dpdk.org; Hiroyuki Mikita; olivier.matz@6wind.com >> Subject: Re: [dpdk-dev] [PATCH v2] mbuf: decrease refcnt when detaching >> >> 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. > > I still think it is better to have it then not, but wouldn't insist here. > Konstantin > >> If you need the feature "attach to raw", please implement it completely. >