From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: Reshuffling of rte_mbuf structure. Date: Mon, 02 Nov 2015 23:51:23 +0100 Message-ID: <2014794.RrzFoKiHXW@xps13> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: "shesha Sreenivasamurthy (shesha)" , Arnon Warshavsky Return-path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id A22538D96 for ; Mon, 2 Nov 2015 23:52:34 +0100 (CET) Received: by wmeg8 with SMTP id g8so71363239wme.0 for ; Mon, 02 Nov 2015 14:52:34 -0800 (PST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" This discussion is about improving performance of specific use cases by moving the mbuf fields when needed. We could consider how to configure it and how complicated it would be to write applications or drivers (especially vector ones) for such a moving structure. But it is simpler to say that having an API depending of some options is a "no-design" which could seriously slow down the DPDK adoption. You can have a different opinion but I cannot imagine how strong must be the arguments to make it happen.