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 D1DA1B3F1 for ; Fri, 13 Feb 2015 09:41:48 +0100 (CET) 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.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YMBsS-0004Tm-45; Fri, 13 Feb 2015 09:45:36 +0100 Message-ID: <54DDB8BF.8070208@6wind.com> Date: Fri, 13 Feb 2015 09:41:35 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: "Zhang, Helin" , "dev@dpdk.org" References: <1422623775-8050-1-git-send-email-olivier.matz@6wind.com> <1423041925-26956-1-git-send-email-olivier.matz@6wind.com> <1423041925-26956-4-git-send-email-olivier.matz@6wind.com> <54DA3AB0.3040500@6wind.com> <54DB8DC0.500@6wind.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 03/20] i40e: call i40e_txd_enable_checksum only for offloaded packets 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, 13 Feb 2015 08:41:49 -0000 Hi, On 02/13/2015 03:25 AM, Zhang, Helin wrote: >> On 02/11/2015 06:32 AM, Zhang, Helin wrote: >>>> On 02/10/2015 07:03 AM, Zhang, Helin wrote: >>>>>> /* Enable checksum offloading */ >>>>>> cd_tunneling_params = 0; >>>>>> - i40e_txd_enable_checksum(ol_flags, &td_cmd, &td_offset, >>>>>> - l2_len, l3_len, outer_l2_len, >>>>>> - outer_l3_len, >>>>>> - &cd_tunneling_params); >>>>>> + if (ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) { >>>>> likely should be added. >>>> >>>> I would say unlikely() instead. I think the non-offload case should >>>> be the default one. What do you think? >> >> Maybe you missed this comment. Any thoughts? > Ohh, sorry for the missing! > I'd prefer to have likely, as hardware offload is preferred if there is. If you > don't think so, how about to keep nothing (no likely/unlikely) as it is. OK, I'll use likely() as you initially suggested. >>> As 40G is quite sensitive on cpu cycles, we'd better to avoid any >>> performance drop during our modifying the code for fast path. >>> Performance is what we care about too much. Based on my experiences, >>> even minor code changes may result in big performance impact. >>> It seems that we may need to help you on performance measurement. >> >> Thanks, indeed it's helpful if you can check performance non-regression. > I have asked our validation guys here to help you on that, but might not in > high priority. In addition, we all will take vocation for the coming Chinese new year. OK, it's noted Thanks, Olivier