From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 335EE43CB8 for ; Fri, 15 Mar 2024 10:38:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9221F42DCA; Fri, 15 Mar 2024 10:38:28 +0100 (CET) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mails.dpdk.org (Postfix) with ESMTP id 4C7A64027B for ; Fri, 15 Mar 2024 10:38:27 +0100 (CET) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-513cfc93f4eso2091978e87.3 for ; Fri, 15 Mar 2024 02:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710495507; x=1711100307; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=gtmxEgGKGahZCTky/ttpSG7WAjFdDcIIBPtSIpqLohg=; b=W2He9lsYBDVYqyfoOCggMzMvWE8o2II76w3R6SPUcWf5jpQHtXY+x16GdWRZHnFIkL GwJrnvyqr6jTEaVbdAMwFmdKsrhGSJ55iSjh/A5ctcMtRTmepwYILo+LYxamPEgOZ/q4 7O5mUQpENzfP2CCsZCQm20AE2JRARUgp/kIvDZP5eEi2UPstTQ8LznhwJCP30SeOxG+H NYCJ986WuBoqUkGNAqp2PvqYVnPvp7cjPhG001zQz3eQH64vCctaWXK7STZLTULPTlly t75Ge1QIGjsuIAxwq6htRzst5YQZ4ZcSx7y6Ui4I/m2RQHD8+gPTSzS/l7RiffjC/2J8 c/4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710495507; x=1711100307; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gtmxEgGKGahZCTky/ttpSG7WAjFdDcIIBPtSIpqLohg=; b=d0GDxtPZQoPyuiUHohc8OiwJIZCYyFfXyEjydHqKo1ZafnUrTY0EXkIGYj4KckDjIQ DocFOl46gzect+oVkDiHDcj/yCOhIqFJsXgs0wm3DuCsiuSxcZxPXtj6lz92P9QR+r6l hA8lx8KQkJZBERRTM8YLIELJC3huCGjj3izY+oXKMfvqbMmY4mBU6wQuDm3+py3cnVpr wOH1SKvBmqLF4eUQbMtv+sTRszNgBeX7GJuC3CP6XOg6B5OKKCHn6IQJIPqLTrRWzLuW kFS5KxFv5JcYYdTtaWW++Vv2h/weFAegOUism7oqvf3VY0LVHdg8Oeu7dc6SNC+6FxkL zNDA== X-Gm-Message-State: AOJu0YyDxtm3jEDFWoyY1AnbKs5tVPJMPwn2EacgaQ8xjNxKxvxHCXNp 1MYzN7h1FMPTewnNna+hxsBy7bYOLqR9ITJYxbhuwnx9UzHGvtry X-Google-Smtp-Source: AGHT+IGFnin+9JTBXmbefIxgia5mkC65jDPGAIYDOif4KArjQ9D3U/DDj+WruZU6dlYBHjq1lBqMvg== X-Received: by 2002:a19:6914:0:b0:513:bcaf:c339 with SMTP id e20-20020a196914000000b00513bcafc339mr3204843lfc.13.1710495506413; Fri, 15 Mar 2024 02:38:26 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id q18-20020a05651232b200b00513a7b47c75sm592890lfe.93.2024.03.15.02.38.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 02:38:25 -0700 (PDT) Date: Fri, 15 Mar 2024 12:38:24 +0300 From: Dmitry Kozlyuk To: Jakob Wieckowski Cc: users@dpdk.org Subject: Re: dynamic and variable mbuf size Message-ID: <20240315123824.1f59a78f@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org 2024-03-15 08:47 (UTC+0100), Jakob Wieckowski: > Hello DPDK Users, > > I have a question regarding the size of mbufs. > The mbuf are contained in the mempol and the mempool is a fixed size object. > > Could the mbuf be implemented dynamically with a variable size in the > mempool area ? > > In the header of the mbuf you could specify the size of the payload data > and thus could expand the size of the mbufs. > > From my understanding, you just have to keep an eye on the mempool memory > size so that it doesn't go beyond the limit of the allocated area. > > Would this be generally possible? Hi, If mbufs could be allocated of any size, mempool would be a general-purpose allocator, but there is a tradeoff between generality and performance, and rte_mempool pursuits the latter. The size of an mbuf data may only be adjusted, but only up to the size specified at mempool creation. There are solutions for some use cases: - using multiple mempools for objects of different size - some NICs can split packets allocating segments from different mempools - mbufs can be chained - rte_pktmbuf_attach_extbuf() + custom allocator - "memarea" proposed library [1] (looks very similar to what you describe) What is you usage scenario? [1]: http://inbox.dpdk.org/dev/20230720092254.54157-1-fengchengwen@huawei.com/