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 D848C6946 for ; Thu, 15 May 2014 18:30:12 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 15 May 2014 09:25:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,1060,1389772800"; d="scan'208";a="512264017" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga001.jf.intel.com with ESMTP; 15 May 2014 09:30:16 -0700 Received: from irsmsx107.ger.corp.intel.com (163.33.3.99) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 15 May 2014 17:30:16 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.70]) by IRSMSX107.ger.corp.intel.com ([169.254.10.172]) with mapi id 14.03.0123.003; Thu, 15 May 2014 17:30:15 +0100 From: "Ananyev, Konstantin" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH RFC 11/11] ixgbe/mbuf: add TSO support Thread-Index: AQHPa5ZWUBVmR8JmOEOPGVNhAVBtGJtBxefg///59wCAABPWgA== Date: Thu, 15 May 2014 16:30:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580EFA6B2A@IRSMSX105.ger.corp.intel.com> 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> In-Reply-To: <5374DFC4.50808@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 15 May 2014 16:30:13 -0000 Hi Oliver, With the current DPDK implementation the upper code would still be differen= t for TCP checksum (without segmentation) and TCP segmentation: different flags in mbuf, with TSO you need to setup l4_len and mss fields i= nside mbuf, with just checksum - you don't. Plus, as I said, it is a bit confusing to calculate PSD csum once in the st= ack 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 t= estpmd/csumonly.c and call them accordingly? About potential future problem with NICs that implement TX checksum/segment= ation offloads in a different manner - yeh that's true... I think at the final point all that logic could be hidden inside some funct= ion at rte_ethdev level, something like: rte_eth_dev_prep_tx(portid, mbuf[= ], num). So, based on mbuf TX offload flags and device type, it would do necessary = modifications inside the packet. =20 But that's future discussion, I suppose. For now, I still think we need to keep pseudo checksum calculations out of = PMD code. Konstantin -----Original Message----- From: Olivier MATZ [mailto:olivier.matz@6wind.com]=20 Sent: Thursday, May 15, 2014 4:40 PM To: Ananyev, Konstantin; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 11/11] ixgbe/mbuf: add TSO support Hi Konstantin, On 05/15/2014 05:09 PM, Ananyev, Konstantin wrote: > By design PMD not supposed to touch (or even look) into actual packet's d= ata. I agree on the principle, we should avoid that as much as possible. > That is one of the reason why we put l2/l3/l4_len fields into the mbuf it= self. > Also it seems a bit strange to calculate one pseudo-header checksum in th= e upper layer and then > Recalculate it again inside testpmd/ > So I wonder is it possible to move fix_tcp_phdr_cksum() logic into the up= per layer > (testpmd pkt_burst_checksum_forward())? The reason why I did this is to define a generic PMD API for TSO: Today, if you want to want to offload checksum calculation on tx, the network stack has to calculate the pseudo header checksum. Even if it could be calculated by the hardware, it's not a problem to calculate it by software. Now, because of the hardware, if you do TCP segmentation offload, you have to calculate the pseudo-header checksum without including the ip len. It seems to me that it adds some complexity because, depending on the hardware configuration, the stack has to behave differently. It seemed more logical to me that the network code that generates TCP packets has to be identical whatever the driver options. Moreover, if tomorrow we add another PMD that needs the pseudo-header with ip_len in all case (TSO or not), we would have to do the same kind function than fix_tcp_phdr_cksum(). So, I tried to define the API in order to simplify the work of the network stack developper, even if it does not map the hardware behavior. Nevertheless, I'm open to discuss it. Regards, Olivier