From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by dpdk.org (Postfix) with ESMTP id 0B55EE5D for ; Tue, 24 Apr 2018 07:01:10 +0200 (CEST) Received: by mail-pg0-f49.google.com with SMTP id p10so9953270pgn.1 for ; Mon, 23 Apr 2018 22:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=c5Fz2Mr2KCZW7UoRa7AcWuvGLTHREq0TZSs7E61HYjQ=; b=NNQ3djNzspuM1dcaaVSUtmT+pmm8t2fFg9TqSSuwXHISdNxu5wHVHuX4FhCdV/QPhW dmYF3hgqzti6TJWgTDmbbIgaRv83No9X1pc7O1zr/VIPQOQGOrxwGottPuj2sYyGiEeF Q6WQdUm6kHPZbqI8sB2uc7n3muhp6J+kUG571FDA75ebf4RbrzmJBYkYN2yfLp91IZWA NS1jvfRKtNzu3X1UJpOPp2nPfBJartkjMwzYJ+9iWrO1huHdEYQH15/hXKyZ0TJlFO/J 9VSZnUSylm8Cj4CT3nTxay2n7nWSKxlP0FoGQi+QONt91KboCc29P0fqMfKrKZSKbYkG viqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=c5Fz2Mr2KCZW7UoRa7AcWuvGLTHREq0TZSs7E61HYjQ=; b=fl6wGAdwsfqK8fB1nNAuS6TtuBFDXt1/yVcafqmMUwGvuGrjn65HEU+suawdbCbGKW tN8uJrqaQMqotyC69NQEARCj+WOY+/NB960eSzxQ6R/QC7ag5wwLenK0ZLMW9CCq6qyA 6y7J/MeC4HpU88qgY1T/wSdsHa+8fB9iRo5S/mggw7Tl92J0sayfCZPTJhZyqxueNeza zLz4kyCFPV60F3uLL+PN9jxG3ZfpXOH9rVIeP9sL2uanjEFm2yvfTt7P2h2JHHWXfSuk qoI5FigM59fAl9j0UYe6DGvCxOJV94GCtRPSfkHCUosCSI3UiGfRBLu9RcNAoavOImwx ayVg== X-Gm-Message-State: ALQs6tCVeHkyKgcaCoTOTAeFy1boCTzJ/Jw1sqiikUo/nDJcv4SMSiek hZIn//CTGxF4Rl7L5h4lUWdgWg== X-Google-Smtp-Source: AIpwx4982MXKE1QP3BnSK9WYf5agDZ7EsIZhYXUXk/Hyvn0oZh8TZglJ5SkD2KqSDMnzBMiYpsvr4g== X-Received: by 10.101.69.198 with SMTP id m6mr19154798pgr.244.1524546069822; Mon, 23 Apr 2018 22:01:09 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id d23sm22798012pfn.22.2018.04.23.22.01.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Apr 2018 22:01:09 -0700 (PDT) Date: Mon, 23 Apr 2018 22:01:07 -0700 From: Stephen Hemminger To: Yongseok Koh Cc: wenzhuo.lu@intel.com, jingjing.wu@intel.com, olivier.matz@6wind.com, dev@dpdk.org, konstantin.ananyev@intel.com, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com Message-ID: <20180423220107.4d221e6e@xeon-e3> In-Reply-To: <20180424013854.33749-1-yskoh@mellanox.com> References: <20180310012532.15809-1-yskoh@mellanox.com> <20180424013854.33749-1-yskoh@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 1/2] mbuf: support attaching external buffer to mbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 05:01:11 -0000 On Mon, 23 Apr 2018 18:38:53 -0700 Yongseok Koh wrote: > This patch introduces a new way of attaching an external buffer to a mbuf. > > Attaching an external buffer is quite similar to mbuf indirection in > replacing buffer addresses and length of a mbuf, but a few differences: > - When an indirect mbuf is attached, refcnt of the direct mbuf would be > 2 as long as the direct mbuf itself isn't freed after the attachment. > In such cases, the buffer area of a direct mbuf must be read-only. But > external buffer has its own refcnt and it starts from 1. Unless > multiple mbufs are attached to a mbuf having an external buffer, the > external buffer is writable. > - There's no need to allocate buffer from a mempool. Any buffer can be > attached with appropriate free callback. > - Smaller metadata is required to maintain shared data such as refcnt. > > Signed-off-by: Yongseok Koh I think this is a good idea. It looks more useful than indirect mbuf's for the use case where received data needs to come from a non mempool area. Does it have any performance impact? I would hope it doesn't impact applications not using external buffers. Is it possible to start with a refcnt > 1 for the mbuf? I am thinking of the case in netvsc where data is received into an area returned from the host. The area is an RNDIS buffer and may contain several packets. A useful optimization would be for the driver return mbufs which point to that buffer where starting refcnt value is the number of packets in the buffer. When refcnt goes to 0 the buffer would be returned to the host. One other problem with this is that it adds an additional buffer management constraint on the application. If for example the mbuf's are going into a TCP stack and TCP can have very slow readers; then the receive buffer might have a long lifetime. Since the receive buffers are limited, eventually the receive area runs out and no more packets are received. Much fingerpointing and angry users ensue..