From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com
 [209.85.160.42]) by dpdk.org (Postfix) with ESMTP id 1CF7A58DA
 for <dev@dpdk.org>; Tue, 27 May 2014 02:16:53 +0200 (CEST)
Received: by mail-pb0-f42.google.com with SMTP id md12so8346340pbc.29
 for <dev@dpdk.org>; Mon, 26 May 2014 17:17:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=Dpb4b2m2w16S7KJ8tv76141ldmBN3MDacWUO2moU/qk=;
 b=KzzkGPNKLAU6B49vH090LHunUgEqpXzbfP4uvb+ORCfuFD6Kdk54l2O643UWHk4uEk
 prqxUKyuBT9mvY1qpGlskp0doy150XIKwNa2nP4Yc3GAHjmeQjtQur6qUQeFmmrd3hY0
 gP+GQc4eVMDCcUJsbedt2HP/TlHnBZQ0l9O4U5X4e7QgN08wRlRd2+/juJ1C/ydubTjY
 czUWQzIlOh442biuim2DhCPLkhOU2tMcszabiL0KjeUw+0eQIAQoNV22TW8vwXTa7JGM
 h6iHd3hsY4ftsPgq5BnEJcwAhd0CMFnR493aylE9Udhr2Ilz3/vgNx/Er3GtEARxgsco
 ELkQ==
X-Gm-Message-State: ALoCoQle6cqmScfMDZ3YzMHBXsLFCNPRMFUQczRnIxckV4EkU9/2ZcA8TnXumoj21oU4BflmlIrr
X-Received: by 10.66.121.103 with SMTP id lj7mr22107090pab.97.1401149824341;
 Mon, 26 May 2014 17:17:04 -0700 (PDT)
Received: from nehalam.linuxnetplumber.net
 (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51])
 by mx.google.com with ESMTPSA id gz11sm20176102pbd.1.2014.05.26.17.17.03
 for <multiple recipients>
 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
 Mon, 26 May 2014 17:17:04 -0700 (PDT)
Date: Mon, 26 May 2014 17:17:01 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Olivier Matz <olivier.matz@6wind.com>
Message-ID: <20140526171701.7bd0fadd@nehalam.linuxnetplumber.net>
In-Reply-To: <1399647038-15095-4-git-send-email-olivier.matz@6wind.com>
References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com>
 <1399647038-15095-4-git-send-email-olivier.matz@6wind.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 00:16:54 -0000

On Fri,  9 May 2014 16:50:30 +0200
Olivier Matz <olivier.matz@6wind.com> wrote:

> The initial role of rte_ctrlmbuf is to carry generic messages (data
> pointer + data length) but it's not used by the DPDK or it applications.
> Keeping it implies:
>   - loosing 1 byte in the rte_mbuf structure
>   - having some dead code rte_mbuf.[ch]
> 
> This patch removes this feature. Thanks to it, it is now possible to
> simplify the rte_mbuf structure by merging the rte_pktmbuf structure
> in it. This is done in next commit.
> 
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>

The only win from this is to save the byte for the type field.
Yes bits here are precious.

Does external application mix control and data mbuf's in the same ring?
The stuff in the tree only uses type field for debug validation/sanity
checks.

Since it is only one bit, maybe you can find one bit to store that. 
Since buffer and pool addresses are going to be at least 32 bit aligned
maybe you can use the old GC trick of using the LSB as flag.