From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by dpdk.org (Postfix) with ESMTP id 0251211DE for ; Thu, 16 Mar 2017 17:09:31 +0100 (CET) Received: by mail-pf0-f178.google.com with SMTP id o126so26443815pfb.3 for ; Thu, 16 Mar 2017 09:09:31 -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=5z/e4ep4093zwErLhAhq+nUx40d2pgLiUG/vakwgtL8=; b=OL3PoXgnQmC8eM0r27ju2RpGkswWxZAect98GcWm+NARnSoni7xl0Vx7qp8d23ZbME ZGuKXeDZDpHby2q2Web++vi/uONYrjYnHdt7MCEN7xSihxuh67HHmtFeH7+Kz0W6B4S4 32PFd3p1MVLRLb6ctwjBp/OAEw1b60NaH9raZemiCw6/CJH2UUhNotnvxD6eMjyAiUx7 5w3uhjbT92Kgr3CDzOtdOeL+mr2sOat61ZfF8wsyvUL9vds6UGc6Bm/j9oa8L8zAVFQw vSkZFactbMs2oZ3udIjAmgR0891wwVuUDQsdyyjPkzIVWB7scaHm/srrLwLz9vMXoleY wMiA== 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=5z/e4ep4093zwErLhAhq+nUx40d2pgLiUG/vakwgtL8=; b=MV6q4/YJekLrT1ObTiQ1PjzJo50N82m01ojbhcFUQmauCJgdE6I4cioPJ5faM3PbCZ tSjVVmrnMTo+jZebhp8EBJV+ekcMgLxozqgDKhcuzK1gdrhnk7OTFxlhxP/ETd614Fk2 gQWnSlZ3cfwKga3hzr6yfP1KkkvZ1LC0wbKzloH6BZwu8AIdneVv9HZsh94onJq40B9s KeHf/EJh81pe10QKj3sK8gEaO7+rBigXiYOTUDOPGvA/BYCguURWDdhD9JGhrK8GPoN3 Ai+e0PjV3W9PlUr/bTZ+wygGwNp208yqn6EiIYwF68FNF1YIrlvfhL8ZFOey0AmEzh5G eNuQ== X-Gm-Message-State: AFeK/H0Wq2SKYIyaEUx0zaTtdw9gENW2rCRLC004VDRyqmbKIwLJyKWRJ9TBi8yqYF1Pqg== X-Received: by 10.98.93.150 with SMTP id n22mr11466500pfj.103.1489680571190; Thu, 16 Mar 2017 09:09:31 -0700 (PDT) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id g64sm11497236pfc.57.2017.03.16.09.09.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 16 Mar 2017 09:09:31 -0700 (PDT) Date: Thu, 16 Mar 2017 09:09:23 -0700 From: Stephen Hemminger To: "Wiles, Keith" Cc: Mike Shang , "users@dpdk.org" Message-ID: <20170316090923.31f26bfc@xeon-e3> In-Reply-To: <1645CF06-8334-4E53-85DB-DE4D566B5D6E@intel.com> References: <1645CF06-8334-4E53-85DB-DE4D566B5D6E@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] manually construct 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, 16 Mar 2017 16:09:32 -0000 On Thu, 16 Mar 2017 03:41:14 +0000 "Wiles, Keith" wrote: > > On Mar 16, 2017, at 11:28 AM, Mike Shang wrote: > > > > Is it possible to construct mbuf manually instead getting one from > > mempool ? I've got a situation that needs to handle a relatively small > > number of jumbo frames, we keep a mempool of objects of regular size and > > wanted to construct mbuf ourselves for jumbo frames as one segment using > > rte_malloc. I have searched the dpdk source code a bit but can't find such > > use case. Is it doable with dpdk ? Or it's recommended to keep a separate > > mempool for objects of larger size ? > > You could try to construct your own mbuf, but when the system attempts to free the mbuf you would need to build a lot more then just the mbuf as the mempool pointer is hiding in the data/mbuf and it expects to point to a valid mempool. > > What I would do is just allocate a couple jumbo mbuf in a new mempool allocation and use those mbufs when you want to send jumbo frames. Trying to create a special mbuf is not going to super simple, just create a new mempool with N number of mbufs. Or teach your code how to use chained multi-segment mbuf's. That is the right way to handle larger data without having to pin down large chunks of memory.