From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 4D5207EB0 for ; Thu, 4 Dec 2014 18:11:44 +0100 (CET) Received: by mail-wg0-f54.google.com with SMTP id l2so23273172wgh.41 for ; Thu, 04 Dec 2014 09:11:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IHp6tIpUwFnpAP6JNIVr0aneK7rw1v7Zy7zF0hOkAsc=; b=as7pxjlGPCDA4Z50grU/uzSnW9b6GOOZYBg/6n3u5RwPcYRqBXI9Vwd6ebyQ+BEmEj ogcxUW9N3F5eIyNMvzl3r/aXTclCDRAsliSIwQwZu6gyAqXFaDYnRMbaOvvj78VQ/BKu HW4/6A6wpEQF9k+TablWnOthiVZgVcuephgHkCWg+cz+bv34k60u0lpxzlmkOB3TfP9W Jq68ouXdlTyr6sOqHyybMeA4A5h/wXPBrBfQvMoJa9e/UsnwsW2vPBkLSTeMhJpHHhMt xFGaTXBIJazPnvv+D6o1ch4Vxd+UE1CCevfkf+m8jDE9OEwzlED4S0nZkExKgtR9cR2q Z6vQ== X-Gm-Message-State: ALoCoQkY0uLZoQF269vJi1eczQDUi1tiRTSs+TAvvsZyhpFjccJrqnj8CNtEcT5v0gmCn4KVIk9K X-Received: by 10.194.179.166 with SMTP id dh6mr13398289wjc.87.1417713104106; Thu, 04 Dec 2014 09:11:44 -0800 (PST) Received: from [192.168.0.8] (crb44-1-82-67-127-5.fbx.proxad.net. [82.67.127.5]) by mx.google.com with ESMTPSA id bj7sm41290931wjc.33.2014.12.04.09.11.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 09:11:43 -0800 (PST) Message-ID: <548095CD.5080607@6wind.com> Date: Thu, 04 Dec 2014 18:11:41 +0100 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bruce Richardson , "Ananyev, Konstantin" References: <1417703181-23093-1-git-send-email-jean-mickael.guerin@6wind.com> <20141204151500.GC9300@bricha3-MOBL3> <2601191342CEEE43887BDE71AB977258213BCA80@IRSMSX105.ger.corp.intel.com> <4349408.QROSJAq1DS@xps13> <2601191342CEEE43887BDE71AB977258213BCAE4@IRSMSX105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258213BCB11@IRSMSX105.ger.corp.intel.com> <20141204165847.GA7732@bricha3-MOBL3> In-Reply-To: <20141204165847.GA7732@bricha3-MOBL3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 2/2] ixgbe: don't override mbuf buffer length 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: Thu, 04 Dec 2014 17:11:44 -0000 >> Which makes me think, that we probably shouldn't overwrite buf_len by rxq->mbuf_initializer. >> > I believe that it is perfectly safe to do so. All buffers from a mempool are meant > to be the same size, therefore reading the length of one buffer should tell you > what size all buffers are. If we do hit a scenario where we do need to support > variable size buffers from a single mempool, we can do that via the older unoptimized > code paths, I think, since it's a definite edge case. > I agree, and there is a place to store some values unique for all mbufs in a pool: struct rte_pktmbuf_pool_private { uint16_t mbuf_data_room_size; /**< Size of data space in each mbuf.*/ }; We could add a new field mbuf_buf_len here, it looks definitely better than new callbacks in rte_mempool. What do you think?