From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 07675593A for ; Fri, 23 May 2014 16:22:21 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WnqO8-0005oo-OE; Fri, 23 May 2014 16:24:13 +0200 Message-ID: <537F599F.20009@6wind.com> Date: Fri, 23 May 2014 16:22:23 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "Venkatesan, Venky" , Thomas Monjalon , "Ananyev, Konstantin" , "Shaw, Jeffrey B" , "Richardson, Bruce" , "nhorman@tuxdriver.com" , "stephen@networkplumber.org" References: <1400507789-18453-1-git-send-email-olivier.matz@6wind.com> <466924555.DZ26nc55Es@xps13> <1FD9B82B8BF2CF418D9A1000154491D9740B9074@ORSMSX102.amr.corp.intel.com> In-Reply-To: <1FD9B82B8BF2CF418D9A1000154491D9740B9074@ORSMSX102.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:22:21 -0000 Hi Venky, > 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 > time - one other option that I've looked at is to let the transmit > offload parts (except for the VLAN) flow onto the second cache > line. That doesn't seem to have a performance hit at this point - > since it's going to be populated before calling transmit anyway, it's > cache hot. Have we thought 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 patch series can justify a really small impact (see my test reports) on demonstration-only applications: my testpmd iofwd test with the txqflags option disabling many mbuf features is not representative of a real world application. In my opinion, moving offload parts outside in another cache line would have 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. 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 or reworks on top it. Regards, Olivier