From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CDC236882 for ; Fri, 23 May 2014 16:43:02 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 23 May 2014 07:43:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,894,1392192000"; d="scan'208";a="536635173" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga001.fm.intel.com with ESMTP; 23 May 2014 07:43:11 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 23 May 2014 07:43:11 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.23]) by ORSMSX152.amr.corp.intel.com ([169.254.8.215]) with mapi id 14.03.0123.003; Fri, 23 May 2014 07:43:11 -0700 From: "Venkatesan, Venky" To: Olivier MATZ , Thomas Monjalon , "Ananyev, Konstantin" , "Shaw, Jeffrey B" , "Richardson, Bruce" , "nhorman@tuxdriver.com" , "stephen@networkplumber.org" Thread-Topic: [PATCH v2 00/17] add TSO support Thread-Index: AQHPdpJyEZM8NpaHBEKLtbM0zYVB/ZtOON7g Date: Fri, 23 May 2014 14:43:10 +0000 Message-ID: <1FD9B82B8BF2CF418D9A1000154491D9740C60E2@ORSMSX102.amr.corp.intel.com> References: <1400507789-18453-1-git-send-email-olivier.matz@6wind.com> <466924555.DZ26nc55Es@xps13> <1FD9B82B8BF2CF418D9A1000154491D9740B9074@ORSMSX102.amr.corp.intel.com> <537F599F.20009@6wind.com> In-Reply-To: <537F599F.20009@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 00/17] add TSO support 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, 23 May 2014 14:43:03 -0000 Olivier,=20 >> It's because we haven't gotten to testing the patch yet, and figuring >= out all the problems. Putting it in and modifying MBUF needs a bit of > t= ime - one other option that I've looked at is to let the transmit > offloa= d parts (except for the VLAN) flow onto the second cache > line. That does= n't seem to have a performance hit at this point - > since it's going to b= e populated before calling transmit anyway, it's > cache hot. Have we thou= ght of simply doing that instead of these > changes that have net negative= side effects in terms of mbuf mods? > I think that the performance gain on a real use case provided by this pat= ch series can justify a really small impact (see my test reports) on demons= tration-only applications: my testpmd iofwd test with the txqflags option d= isabling many mbuf features is not representative of a real world applicati= on. [Venky] I did see your test reports. I also made the point that the tests w= e have are insufficient for testing the impact. If you look at data_ofs, it= actually has an impact on two sides - the driver and the upper layer. We d= o not at this time have a test for the upper layer/accessor. Secondly, ther= e is a whole class of apps (fast path route for example) that aren't in you= r purview that do not need txqflags. Calling it not representative of a rea= l world application is incorrect.=20 Secondly, your testpmd run baseline performance should be higher. At this p= oint, it is about 40% off from the numbers we see on the baseline on the sa= me CPU. If the baseline is incorrect, I cannot judge anything more on the p= erformance. We need to get the baseline performance the same, and then comp= are impact.=20 > In my opinion, moving offload parts outside in another cache line would h= ave an impact on performance. If not, why would you exclude vlan? But this is speculation. As Neil and Thomas suggested previously, we should= rely on performance and functional tests. [Venky] I exclude VLAN because it is something explicitly set by the Rx sid= e of the driver. Having Rx access a second cache line will generate a perfo= rmance impact (can be mitigated by a prefetch, but it will cost more instru= ctions, and cannot be deterministically controlled). The rest of the struct= ure is on the transmit side - which is going to be cache hot - at least in = LLC anyway. There are cases where this will not be in LLC - and we have a f= ew of those. Those however, we can mitigate. > Today, there is no alternative that brings equivalent features and better= performance (I mean there is no patch nor test reports). If the series is = applied after your ack, it won't prevent anyone to bring new enhancements o= r reworks on top it.=20 [Venky] I don't think reworking core data structures (especially regressing= core data structures) is a good thing. We have kept this relatively stable= over 5 releases, sometimes at the impact of performance, and churning data= structures is not a good thing.=20 BR, - Venky