From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by dpdk.org (Postfix) with ESMTP id 5E03BC42A for ; Wed, 17 Jun 2015 15:56:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=934; q=dns/txt; s=iport; t=1434549362; x=1435758962; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=10ugcSzBDsWbrkYJVPFNUlRiP8Nx5LKvN6MuXLzP/U8=; b=FN1Z6k/JeG6MhKBUczNWlvFHRD/W5uZUQSQd+f7Tr+Mt2EWX8j4qaijD AKiHOjJHW+9CWEx0+DXVAgroGVJX4l1NGEW09R0qEsSq/vavWWDuewNYI jsRVh3BQ2Bf3fT+dCiSPp3sNLV+rjHI5uiB550ViE7d0SC/51M/uN1qrS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQCbe4FV/5JdJa1cgxCBMwbFOwKBNjsRAQEBAQEBAYEKhCIBAQEDATo/BQsCAQgYHhAyJQIEDgWIJwjKDwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIRTMweDF4EUAQSTaAGLRoE0hxOFG4o+JoN5b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,632,1427760000"; d="scan'208";a="4289876" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jun 2015 13:56:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5HDtxJi021983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 13:55:59 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.74]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 08:55:59 -0500 From: "Damjan Marion (damarion)" To: Bruce Richardson Thread-Topic: [dpdk-dev] rte_mbuf.next in 2nd cacheline Thread-Index: AQHQo8caZr3uhWmxzEWZx6NE1pCbq52t6FMAgAAGpoCAAALXgIAAAwKAgAACNACAAx/mgA== Date: Wed, 17 Jun 2015 13:55:57 +0000 Message-ID: <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@cisco.com> References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com> <557ED116.7040508@6wind.com> <20150615134409.GA7500@bricha3-MOBL3> <2601191342CEEE43887BDE71AB97725836A0A838@irsmsx105.ger.corp.intel.com> <557EDB91.9010503@6wind.com> <20150615141258.GA580@bricha3-MOBL3> In-Reply-To: <20150615141258.GA580@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.15.243] Content-Type: text/plain; charset="us-ascii" Content-ID: <82F20E46BCF9FA48A8F0E2BDED06E9ED@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline 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: Wed, 17 Jun 2015 13:56:01 -0000 > On 15 Jun 2015, at 16:12, Bruce Richardson w= rote: >=20 > The next pointers always start out as NULL when the mbuf pool is created.= The > only time it is set to non-NULL is when we have chained mbufs. If we neve= r have > any chained mbufs, we never need to touch the next field, or even read it= - since > we have the num-segments count in the first cache line. If we do have a m= ulti-segment > mbuf, it's likely to be a big packet, so we have more processing time ava= ilable > and we can then take the hit of setting the next pointer. There are applications which are not using rx offload, but they deal with c= hained mbufs. Why they are less important than ones using rx offload? This is something p= eople=20 should be able to configure on build time. That should not be too hard to achieve with set of macros. I can come up wi= th the patch... Thanks, Damjan=