From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 709F2AFD7 for ; Fri, 9 May 2014 18:12:19 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 09 May 2014 09:07:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,1019,1389772800"; d="scan'208";a="509094298" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga001.jf.intel.com with ESMTP; 09 May 2014 09:12:20 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.3.54]) by FMSMSX104.amr.corp.intel.com ([169.254.4.213]) with mapi id 14.03.0123.003; Fri, 9 May 2014 09:11:59 -0700 From: "Shaw, Jeffrey B" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield Thread-Index: AQHPa5Y6oEhAQPHLmkuZVbv+E7VQLJs4YDOggAB/JID//4tiAA== Date: Fri, 9 May 2014 16:11:59 +0000 Message-ID: <4032A54B6BB5F04B8C08B6CFF08C59285542085B@FMSMSX103.amr.corp.intel.com> References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-6-git-send-email-olivier.matz@6wind.com> <4032A54B6BB5F04B8C08B6CFF08C59285542081E@FMSMSX103.amr.corp.intel.com> <536CFCEF.4080704@6wind.com> In-Reply-To: <536CFCEF.4080704@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield 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: Fri, 09 May 2014 16:12:21 -0000 I agree, we should wait for comments then test the performance when the pat= ches have settled. -----Original Message----- From: Olivier MATZ [mailto:olivier.matz@6wind.com]=20 Sent: Friday, May 09, 2014 9:06 AM To: Shaw, Jeffrey B; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len = in a bitfield Hi Jeff, Thank you for your comment. On 05/09/2014 05:39 PM, Shaw, Jeffrey B wrote: > have you tested this patch to see if there is a negative impact to=20 > performance? Yes, but not with testpmd. I passed our internal non-regression performance= tests and it shows no difference (or below the error margin), even with lo= w overhead processing like forwarding whatever the number of cores I use. > Wouldn't the processor have to mask the high bytes of the physical=20 > address when it is used, for example, to populate descriptors with=20 > buffer addresses? When compute bound, this could steal CPU cycles=20 > away from packet processing. I think we should understand the=20 > performance trade-off in order to save these 2 bytes. I would naively say that the cost is negligible: accessing to the length is= the same as before (it's a 16 bits field) and accessing the physical addre= ss is just a mask or a shift, which should not be very long on an Intel pro= cessor (1 cycle?). This is to be compared with the number of cycles per pac= ket in io-fwd mode, which is probably around 150 or 200. > It would be interesting to see how throughput is impacted when the=20 > workload is core-bound. This could be accomplished by running testpmd=20 > in io-fwd mode across 4x 10G ports. I agree, this is something we could check. If you agree, let's first wait f= or some other comments and see if we find a consensus on the patches. Regards, Olivier