From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by dpdk.org (Postfix) with ESMTP id 32065AFCD for ; Thu, 15 May 2014 17:39:43 +0200 (CEST) Received: by mail-we0-f172.google.com with SMTP id k48so1282887wev.3 for ; Thu, 15 May 2014 08:39:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ODpOayQxutomykE/GW+JjdV9tnwy0QLpXauLXbxhk7c=; b=D51AV/kZmSn0IztLUpZYs4Lpes32uteNLqEbkCgrkl4TfwLadb5D33OOUYvObS2mZ7 /MO0I74NPxfuVrZWFLNvznsLvaZLLS+6NTpoJz5CIgoNAF8D5NTI3M6bmp/aViugWZxX mkuKgGB+RYfY+9pADZzt7zhfqF2UYVRps87R5HHiZZ2UEKnMOZ753c3E7xNwwTKmrgmE Hm0sPMgkZrbWreuADZkWZDy4ldTtVMFC84cII80vC7X6zPpKZmTlG5X/EnaTeMxpUKWr 15uscZLlDq6ZhXBlM8+kLgjXH6DgbbIYdFEdt3CBjuR3sMbeiBSjh2EvuTWqSGO0MbPT /mQw== X-Gm-Message-State: ALoCoQlbTaYKLoj6lCisvdW0v9lKDgyjsBWBw8nH4wUYOF/vG3uWQRaUnpaeZrwa08WxImEwJW3v X-Received: by 10.194.188.68 with SMTP id fy4mr9225922wjc.30.1400168390852; Thu, 15 May 2014 08:39:50 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id wo9sm7229270wjb.48.2014.05.15.08.39.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 08:39:50 -0700 (PDT) Message-ID: <5374DFC4.50808@6wind.com> Date: Thu, 15 May 2014 17:39:48 +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> In-Reply-To: <2601191342CEEE43887BDE71AB9772580EFA6ADD@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: Thu, 15 May 2014 15:39:43 -0000 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 data. 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 itself. > Also it seems a bit strange to calculate one pseudo-header checksum in the upper layer and then > Recalculate it again inside testpmd/ > So I wonder is it possible to move fix_tcp_phdr_cksum() logic into the upper 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