From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id B508868A8 for ; Mon, 8 Sep 2014 11:50:53 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XQviK-0007gP-KA; Mon, 08 Sep 2014 11:58:27 +0200 Message-ID: <540D7D1E.1020500@6wind.com> Date: Mon, 08 Sep 2014 11:55:42 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Bruce Richardson , dev@dpdk.org References: <1409759378-10113-1-git-send-email-bruce.richardson@intel.com> <1409759378-10113-2-git-send-email-bruce.richardson@intel.com> <540D7C5F.8000406@6wind.com> In-Reply-To: <540D7C5F.8000406@6wind.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 01/13] mbuf: replace data pointer by an offset 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: Mon, 08 Sep 2014 09:50:53 -0000 >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >> index 32e8474..669e7f5 100644 >> --- a/lib/librte_mbuf/rte_mbuf.h >> +++ b/lib/librte_mbuf/rte_mbuf.h >> @@ -119,6 +119,13 @@ struct rte_mbuf { >> void *buf_addr; /**< Virtual address of segment buffer. */ >> phys_addr_t buf_physaddr; /**< Physical address of segment buffer. */ >> uint16_t buf_len; /**< Length of segment buffer. */ >> + >> + /* valid for any segment */ >> + struct rte_mbuf *next; /**< Next segment of scattered packet. */ >> + uint16_t data_off; >> + uint16_t data_len; /**< Amount of data in segment buffer. */ >> + uint32_t pkt_len; /**< Total pkt len: sum of all segments. */ >> + > > Here, the compiler will add some padding between "buf_len" and "next" > (6 bytes in 64bits, 2 in 32bits). Shouldn't we add "reserved" fields > or at least a comment ? Another idea would be to reorganize the fields > to avoid padding, if possible. I've just seen that patch 02/13 reorders the mbuf fields. So maybe this remarq is useless. Olivier