From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id A3A752C24 for ; Sun, 19 Feb 2017 20:05:01 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2017 11:05:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,182,1484035200"; d="scan'208";a="1112872881" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga001.fm.intel.com with ESMTP; 19 Feb 2017 11:04:59 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.197]) by IRSMSX108.ger.corp.intel.com ([169.254.11.173]) with mapi id 14.03.0248.002; Sun, 19 Feb 2017 19:04:58 +0000 From: "Chilikin, Andrey" To: Olivier Matz CC: "Ananyev, Konstantin" , "Richardson, Bruce" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization Thread-Index: AQHSdlXOAsfNlW4HDU+ADPUQ2mOEIqFcZJOAgA9lXICAACEGgIAE6Tew Date: Sun, 19 Feb 2017 19:04:58 +0000 Message-ID: References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170216154619.GA115208@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20170216154619.GA115208@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjI1MTIxYTMtNGU3My00N2ZhLWI4ZTMtMmE2ODlmODg3NWVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJKZnVhT25FR080QjNmNnRjY1BNT3h1VFZqdWZJTGxId21lTytKR1wvNmZOQT0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 19:05:02 -0000 While doing this fields reshuffling, any chance to put uint16_t vlan_tci_o= uter beside uint16_t vlan_tci? It will allow to treat QinQ tags as a single= 32-bit tag, if needed, and use it for other tag/labels like MPLS, GRE, NSH= which could be 20, 24, 32 bits wide. /Andrey > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 24, 2017 3:19 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization >=20 > Based on discussion done in [1], this patchset reorganizes the mbuf. >=20 > The main changes are: > - reorder structure to increase vector performance on some non-ia > platforms. > - add a 64bits timestamp field in the 1st cache line > - m->next, m->nb_segs, and m->refcnt are always initialized for mbufs > in the pool, avoiding the need of setting m->next (located in the > 2nd cache line) in the Rx path for mono-segment packets. > - change port and nb_segs to 16 bits > - move seqn in the 2nd cache line >=20 > Things discussed but not done in the patchset: > - move refcnt and nb_segs to the 2nd cache line: many drivers sets > them in the Rx path, so it could introduce a performance regression, or > it would require to change all the drivers, which is not an easy task. > - remove the m->port field: too much impact on many examples and > libraries, > and some people highlighted they are using it. > - moving m->next in the 1st cache line: there is not enough room, and hav= ing > it set to NULL for unused mbuf should remove the need for it. > - merge seqn and timestamp together in a union: we could imagine use case= s > were both are activated. There is no flag indicating the presence of se= qn, > so it looks preferable to keep them separated for now. >=20 > I made some basic performance tests (ixgbe) and see no regression, but th= e > patchset requires more testing. >=20 > [1] http://dpdk.org/ml/archives/dev/2016-October/049338.html >=20 >=20 > Jerin Jacob (1): > mbuf: make rearm data address naturally aligned >=20 > Olivier Matz (7): > mbuf: make segment prefree function public > mbuf: make raw free function public > mbuf: set mbuf fields while in pool > net: don't touch mbuf next or nb segs on Rx > mbuf: use 2 bytes for port and nb segments > mbuf: move sequence number in second cache line > mbuf: add a timestamp field >=20 > app/test-pmd/csumonly.c | 4 +- > drivers/net/ena/ena_ethdev.c | 2 +- > drivers/net/enic/enic_rxtx.c | 2 +- > drivers/net/fm10k/fm10k_rxtx.c | 6 +- > drivers/net/fm10k/fm10k_rxtx_vec.c | 9 +- > drivers/net/i40e/i40e_rxtx_vec_common.h | 6 +- > drivers/net/i40e/i40e_rxtx_vec_sse.c | 11 +- > drivers/net/ixgbe/ixgbe_rxtx.c | 10 +- > drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 6 +- > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 9 -- > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 9 -- > drivers/net/mlx5/mlx5_rxtx.c | 11 +- > drivers/net/mpipe/mpipe_tilegx.c | 3 +- > drivers/net/null/rte_eth_null.c | 2 - > drivers/net/virtio/virtio_rxtx.c | 3 - > drivers/net/virtio/virtio_rxtx_simple.h | 6 +- > .../linuxapp/eal/include/exec-env/rte_kni_common.h | 5 +- > lib/librte_mbuf/rte_mbuf.c | 4 + > lib/librte_mbuf/rte_mbuf.h | 114 +++++++++++++++= +----- > 19 files changed, 124 insertions(+), 98 deletions(-) >=20 > -- > 2.8.1