From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id E9AC410D7F for ; Thu, 22 Dec 2016 18:01:00 +0100 (CET) Received: by mail-wm0-f68.google.com with SMTP id u144so37237391wmu.0 for ; Thu, 22 Dec 2016 09:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JrKqetfJMiDflmMlBjqB6dS8CBCWbwDe8s1fUcqY/hw=; b=H5uum0U6RnhjWa4Z4/OVDqwRknwijOGwLSQl8WnCgUgLtb0T1YawF7h2GXDMfQi5qq Ce4aGUHLSbLPWdyd1FABl+E2MSjpmAcfVHQK+rUt7Kd/OAPvZB5ISUc7CXG+azOu73DI 1NOQDdJSMGUqXJG6T+ByOAECeS1EVkf49QBzrMTDFjjsAswC41CntWSENJbhwmBSDYmj aXztOKCsivnm5d1LrIACcwxLmKfaMSpZ5jQ2y4PTDo3O8h3K21d5p7GUupNOzruloUcD z5MQoXr0zNU7n4zONWVJQZVHBO562buLJNlTVEATYzf+lJUU0fd+znsFfOgeeQWxLy4i 6L1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JrKqetfJMiDflmMlBjqB6dS8CBCWbwDe8s1fUcqY/hw=; b=mePqPTxxntoZRSNKaEU9IcyZTGZG7cOKIDM0lZIxSJiDYsXKvKNh4q6Ixwl6kIIu+d bZG02YKjed7Uu54UnOFNX95zFZlbLjZly1oMyy1haAm87sRUqDv9bfuvxeebg/qhhlQO Z5sPPXsBTrDWC2cffkf3cNytVlKHkM73QTDKl3v13zojmGdHyBvB7sloEy7FaMzDnjVZ kBmW+ojSW96qrRapxkBIlGxA/EecHclBG6Q7aSwWcfI1WXAhF1fCyu/WmSt1H8e5eqKq Gwv96BECy+O0lOyMdvDg+EDAfa4D15d6Pfp475J+LoYpAe03Iw5sMTQDpowaoWoxwHpQ OPMA== X-Gm-Message-State: AIkVDXLW2aGry2B5ohVAjBa/TzZhEx5jtErdpZCRIHq158iWt3V8k+AS4BtGNgjmiqYnTGuOE1G4CZ2AJc8pbg== X-Received: by 10.28.185.203 with SMTP id j194mr9969196wmf.73.1482426060507; Thu, 22 Dec 2016 09:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.133 with HTTP; Thu, 22 Dec 2016 09:00:39 -0800 (PST) In-Reply-To: <35D0462D-761F-4C7A-A0F4-FD72EBDFA8EB@cloudsimple.com> References: <35D0462D-761F-4C7A-A0F4-FD72EBDFA8EB@cloudsimple.com> From: Take Ceara Date: Thu, 22 Dec 2016 18:00:39 +0100 Message-ID: To: Kumaraparameshwaran Rathnavel Cc: users@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-users] Freeing up Mbuf X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 17:01:01 -0000 Hi Param, On Thu, Dec 22, 2016 at 5:47 PM, Kumaraparameshwaran Rathnavel wrote: > Hi All, > > The mbuf implementation is similar to the Network Driver of the FreeBSD N= etwork Driver. In DPDK userspace driver it is the responsibility of the rte= _eth_dev implementation to free the memory buffer associated with a Queue w= hen descriptors reach below a threshold. In FreeBSD the user can actually s= pecify the free routine for the mbuf when the transmit routine is called. I= s this implemented in DPDK. I basically will give the data buffer of the ap= plication layer that will be chained with the Transport Layer Headers and I= do not want to free up the routines always. Is this possible? You can send a clone of the mbuf (see rte_pktmbuf_clone). Cloning the mbuf will increase the refcount of the direct mbuf (that stores the actual data). When the driver is done transmitting the clone it will decrement the refcount and only free the direct mbuf if the refcount is 0 (see rte_pktmbuf_free_seg and __rte_pktmbuf_prefree_seg). However, you need to be careful if you plan to change the data stored in the direct mbuf and make sure there are no more clones of the data pending transmission. > > Thanking You, > Param. Regards, Dumitru