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 78F3EB0AB for ; Fri, 16 May 2014 14:11:42 +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 1WlH0u-0003zn-ID; Fri, 16 May 2014 14:13:34 +0200 Message-ID: <53760079.7090106@6wind.com> Date: Fri, 16 May 2014 14:11:37 +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: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-12-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772580EFA6ADD@IRSMSX105.ger.corp.intel.com> <5374DFC4.50808@6wind.com> <2601191342CEEE43887BDE71AB9772580EFA6B2A@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580EFA6B2A@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH RFC 11/11] ixgbe/mbuf: 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, 16 May 2014 12:11:42 -0000 Hi Konstantin, On 05/15/2014 06:30 PM, Ananyev, Konstantin wrote: > With the current DPDK implementation the upper code would still be different for TCP checksum (without segmentation) and TCP segmentation: > different flags in mbuf, with TSO you need to setup l4_len and mss fields inside mbuf, with just checksum - you don't. You are right on this point. > Plus, as I said, it is a bit confusing to calculate PSD csum once in the stack and then re-calculate in PMD. > Again - unnecessary slowdown. > So why not just have get_ipv4_psd_sum() and get_ipv4_psd_tso_sum() inside testpmd/csumonly.c and call them accordingly? Yes, recalculating the pseudo-header checksum without the ip_len is a slow down. This slow down should however be compared to the operation in progress. When you do TSO, you are generally transmitting a large TCP packet (several KB), and the cost of the TCP stack is probably much higher than fixing the checksum. But that's not the main argument: my idea was to choose the proper API that will reduce the slow down for most cases. Let's take the case of a future vnic pmd driver supporting an emulation of TSO. In this case, the calculation of the pseudo header is also an unnecessary slowdown. Also, some other hardware I've seen don't need to calculate a different pseudo header checksum when doing TSO. Last argument, the way Linux works is the same that what I've implemented. See in linux ixgbe driver [1] at line 6461, there is a call to csum_tcpudp_magic() which reprocesses the checksum without the ip_len. On the other hand, that's true that today ixgbe is the only hardware supporting TSO in DPDK. The pragmatic approach could be to choose the API that gives the best performance with what we have (the ixgbe driver). I'm ok with this approach if we accept to reconsider the API (and maybe modifying it) when another PMD supporting TSO will be implemented. > About potential future problem with NICs that implement TX checksum/segmentation offloads in a different manner - yeh that's true... > I think at the final point all that logic could be hidden inside some function at rte_ethdev level, something like: rte_eth_dev_prep_tx(portid, mbuf[], num). I don't see the real difference between: rte_eth_dev_prep_tx(portid, mbuf[], num) rte_eth_dev_tx(portid, mbuf[], num) and: rte_eth_dev_tx(portid, mbuf[], num) /* the tx does the cksum job */ And the second is faster because there is only one pointer dereference. > So, based on mbuf TX offload flags and device type, it would do necessary modifications inside the packet. > But that's future discussion, I suppose. To me, it's not an option to fill that the network stack fills the mbuf differently depending on the device type. For instance, when doing ethernet bonding or bridging, the stack may not know which physical device will be used at the end. So the API to enable TSO on a packet has to be the same whatever the device. If fixing the checksum in the PMD is an unnecessary slowdown, forcing the network stack to check what has to be filled in the mbuf depending on the device type also has a cost. > For now, I still think we need to keep pseudo checksum calculations out of PMD code. To me, there are 2 options: 1/ Update patch to calculate the pseudo header without the ip_len when doing TSO. In this case the API is mapped on ixgbe behavior, probably providing the best performance today. If another PMD comes in the future, this API may change to something more generic. 2/ Try to define a generic API today, accepting that the first driver that supports TSO is a bit slower, but reducing the risks of changing the API for TSO in the future. I'm fine with both options. Regards, Olivier [1] http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?v=3.14#L6434