From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [RFC 0/8] mbuf: structure reorganization
Date: Tue, 21 Feb 2017 10:54:06 +0100
Message-ID: <20170221105406.39045e99@glumotte.dev.6wind.com>
References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com>
 <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com>
 <20170216144807.7add2c71@platinum>
 <98CBD80474FA8B44BF855DF32C47DC359EAD04@smartserver.smartshare.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "Olivier Matz" <olivier.matz@6wind.com>, <dev@dpdk.org>
To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
 [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 898116932
 for <dev@dpdk.org>; Tue, 21 Feb 2017 10:54:14 +0100 (CET)
Received: by mail-wr0-f170.google.com with SMTP id 89so74078584wrr.3
 for <dev@dpdk.org>; Tue, 21 Feb 2017 01:54:14 -0800 (PST)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EAD04@smartserver.smartshare.dk>
List-Id: DPDK patches and discussions <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Morten,

On Tue, 21 Feb 2017 10:22:57 +0100, Morten Br=C3=B8rup
<mb@smartsharesystems.com> wrote:
> Hi Olivier,
>=20
> There has been a lot of debate about the size and location (1st or
> 2nd cache line) of the mbuf fields.
>=20
> May I suggest that you add a comment to each field briefly mentioning
> why it has a specific size (8 or 16 bits) (e.g. by example use case),
> and optionally also why it deserves to be in the first cache line. (A
> comment to the mbuf structure can say that fields manipulated by PMDs
> on ingress generally belong in the 1st cache line.)
>=20
> It's not necessary for all fields, just the non-obvious ones (the
> ones discussed here on the mailing list). It will make the
> information more easily accessible to avoid repeating the same
> discussions in the future.
>=20
> E.g. the port field is 16 bits because a hypervisor can serve more
> than 256 virtual machines. And it is in the 1st cache line because a
> PMD for a multi-port NIC with a shared ingress queue needs to set it
> on ingress.
>=20
> And the refcnt field has the same size as the port field to support
> L3 multicast and L2 port flooding on all ports.
>=20

I understand your point about not rediscussing things several times. I
don't think having a comment for fields is really relevant because it
would add many info that are not useful for the user of the structure,
but I think adding something in the API documentation of the rte_mbuf
structure itself makes sense to me.

I'll add something in the next version of the patch.

Thanks,
Olivier