From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by dpdk.org (Postfix) with ESMTP id 558D468AD for ; Wed, 26 Nov 2014 12:03:47 +0100 (CET) Received: by mail-wi0-f182.google.com with SMTP id h11so4543474wiw.15 for ; Wed, 26 Nov 2014 03:14:43 -0800 (PST) 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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0T9s6ByirR0sVAy8IBgAl1s/SUtQWHUYWXV919dYiHo=; b=HkUKclGVCH/pVNuzKjr0/lHEQle2lMYzybDu8jHRqz48BhkwIuyFatNj/ADXifvysn LYd/i4Pgty6Z41QsWT1UHfjjLtZMkpAMF70YkmsAJtPQYKfSNikH0WQsf+ZN7B79mJ+R 1HXKoGv7nAO2zpbdN5hiiJbYa1mC1TzZ9/MUd+Qbz/YBTg9ThyzfxVskrWlEljx4iyZX dqbSMsbxw8pB36EXqgtWViYnSZb5u+Bh8d8ppOrYPIwRGlPNGu/gb5/UqSFDdh6GaQ5c Zt8O5NoLnUhZoyV/4uhHlgxvy4hpkVgpZK4F9fD1Bk1kgtDs8Dmx4wXPfzq1FO6mbBld t84g== X-Gm-Message-State: ALoCoQm0Zv9UkpLhsqnJL0uNpVLisGu8jPR5CJe9tGiJm3ZfOhp52r53Z7IFZFijazhxJ83zTOTU X-Received: by 10.180.8.102 with SMTP id q6mr39170815wia.72.1417000483740; Wed, 26 Nov 2014 03:14:43 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id wv8sm5750235wjc.44.2014.11.26.03.14.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Nov 2014 03:14:43 -0800 (PST) Message-ID: <5475B622.8030705@6wind.com> Date: Wed, 26 Nov 2014 12:14:42 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1415984609-2484-1-git-send-email-olivier.matz@6wind.com> <1416524335-22753-1-git-send-email-olivier.matz@6wind.com> <1416524335-22753-9-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB977258213BA62A@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BA62A@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "jigsaw@gmail.com" Subject: Re: [dpdk-dev] [PATCH v3 08/13] testpmd: rework csum forward engine 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: Wed, 26 Nov 2014 11:03:47 -0000 Hi Konstantin, On 11/26/2014 11:10 AM, Ananyev, Konstantin wrote: > As I can see you removed code that sets up TX_PKT_IPV4 and TX_PKT_IPV6 of ol_flags. > I think that we need to keep it. > The reason for that is: > With FVL, to make HW TX checksum offload work, SW is responsible to provide to the HW information about L3 header. > Possible values are: > - IPv4 hdr with HW checksum calculation > - IPV4 hdr (checksum done by SW) > - IPV6 hdr > - unknown > So let say to for the packet: ETHER_HDR/IPV6_HDR/TCP_HDR/DATA > To request HW TCP checksum offload, SW have to provide to HW information that it is a packet with IPV6 header > (plus as for ixgbe: l2_hdr_len, l3_hdr_len, l4_type, l4_hdr_len). > That's why TX_PKT_IPV4 and TX_PKT_IPV6 were introduced. > > Yes, it is a change in public API for HW TX offload, but I don't see any other way we can overcome it > (apart from make TX function itself to parse a packet, which is obviously not a good choice). > Note that existing apps working on existing HW (ixgbe/igb/em) are not affected. > Though apps that supposed to be run on FVL HW too have to follow new convention. > > So I suggest we keep setting these flags in csumonly.c Right, I missed these flags. It's indeed an API change, but maybe it makes sense, and setting it is not a big cost for the application. So I would also need to slightly modify the API help in the following patches: - [04/13] mbuf: add help about TX checksum flags - [10/13] mbuf: generic support for TCP segmentation offload I'll send a v4 this afternoon that integrates this change. Do you know precisely when the flags PKT_TX_IPV4 and PKT_TX_IPV6 must be set by the application? Is it only the hw checksum and tso use case? If yes, I'll add it in the API help too. By the way (this is probably off-topic), but I'm wondering if the TX flags should have the same values than the RX flags: #define PKT_TX_IPV4 PKT_RX_IPV4_HDR #define PKT_TX_IPV6 PKT_RX_IPV6_HDR > Apart from that , the patch looks good to me. > And yes, we would need to change the the way we handle TX offload for tunnelled packets. Thank you very much Konstantin for your review. Regards, Olivier