From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id F072C282 for ; Thu, 27 Nov 2014 10:44:48 +0100 (CET) Received: by mail-wi0-f181.google.com with SMTP id r20so7691839wiv.14 for ; Thu, 27 Nov 2014 01:44:48 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mUEhQYV0lDbUnCTd5wLVlUB4O3pJSlibGca3dDaJwiE=; b=X9uJMmdQXvgVEom1LrSwvZGKgaVzAISf3ix2hS3+RKSVm3odEsry7JjdTKA2bVlr7i s3xJnwAloStJn4iYXYxjjzbj3LZI/fO+qhu0LDedoC260eTMrLZzKA8+tG9QAoMqDm0u ZqzH9vS+rkLOqLOsy26h0vhvdsccIgaNLMDVOJ32PKwZpFCAvDtLmyGiWRFNmJUiw00v huNGmMiVvnNfsHWPMN7OesRCf5ScJW2lSTXjNT2myTYGdCLnUi74QHI+Hov92qpQiS6I t5B8bK+FHZ0POQU3P/aVzy6MG2B4t23xHmL/G1n7NldV/Ax0y89TIUp4Hq/TOwUC3lX/ pxXg== X-Gm-Message-State: ALoCoQmZhGSRXOrLPnG16jBP9z5GFhnbfHOjIgw3/OVj5b2qSY7PMl5GS3oOEb/z9/PC6jsjApH4 X-Received: by 10.194.86.165 with SMTP id q5mr14214010wjz.10.1417081488757; Thu, 27 Nov 2014 01:44:48 -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 js5sm23922773wid.11.2014.11.27.01.44.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 01:44:48 -0800 (PST) Message-ID: <5476F28F.7010802@6wind.com> Date: Thu, 27 Nov 2014 10:44:47 +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: Jijiang Liu , dev@dpdk.org References: <1417076319-629-1-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1417076319-629-1-git-send-email-jijiang.liu@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework 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, 27 Nov 2014 09:44:49 -0000 Hi Jijiang, Please find below some comments about the specifications. The global picture looks fine to me. I've not reviewed the patch right now, but it's in the pipe. On 11/27/2014 09:18 AM, Jijiang Liu wrote: > We have got some feedback about backward compatibility of VXLAN TX checksum offload API with 1G/10G NIC after the i40e VXLAN TX checksum codes were applied, so we have to rework the APIs on i40e, including the changes of mbuf, i40e PMD and csum engine. > > The main changes in mbuf are as follows, > In place of removing PKT_TX_VXLAN_CKSUM, we introducing 2 new flags: PKT_TX_OUT_IP_CKSUM, PKT_TX_UDP_TUNNEL_PKT, and a new field: l4_tun_len. What about PKT_TX_OUT_UDP_CKSUM instead of PKT_TX_UDP_TUNNEL_PKT? It's maybe more coherent with the other names. > Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len field. > > The existing flags are listed below, > PKT_TX_IP_CKSUM: HW IPv4 checksum for non-tunnelling packet/ HW inner IPv4 checksum for tunnelling packet > PKT_TX_TCP_CKSUM: HW TCP checksum for non-tunnelling packet/ HW inner TCP checksum for tunnelling packet > PKT_TX_SCTP_CKSUM: HW SCTP checksum for non-tunnelling packet/ HW inner SCTP checksum for tunnelling packet > PKT_TX_UDP_CKSUM: HW SCTP checksum for non-tunnelling packet/ HW inner SCTP checksum for tunnelling packet > PKT_TX_IPV4: IPv4 with no HW checksum offload for non-tunnelling packet/inner IPv4 with no HW checksum offload for tunnelling packet > PKT_TX_IPV6: IPv6 non-tunnelling packet/ inner IPv6 with no HW checksum offload for tunnelling packet As I suggested in the TSO thread, I think the following semantics is easier to understand for the user: - PKT_TX_IP_CKSUM: tell the NIC to compute IP cksum - PKT_TX_IPV4: tell the NIC it's an IPv4 packet. Required for L4 checksum offload or TSO. - PKT_TX_IPV6: tell the NIC it's an IPv6 packet. Required for L4 checksum offload or TSO. I think it won't make a big difference in the FVL driver. > let's use a few examples to demonstrate how to use these flags: > Let say we have a tunnel packet: eth_hdr_out/ipv4_hdr_out/udp_hdr_out/vxlan_hdr/ehtr_hdr_in/ipv4_hdr_in/tcp_hdr_in.There could be several scenarios: > > A) User requests HW offload for ipv4_hdr_out checksum. > He doesn't care is it a tunnelled packet or not. > So he sets: > > mb->l2_len = eth_hdr_out; > mb->l3_len = ipv4_hdr_out; > mb->ol_flags |= PKT_TX_IPV4_CSUM; > > B) User is aware that it is a tunnelled packet and requests HW offload for ipv4_hdr_in and tcp_hdr_in *only*. > He doesn't care about outer IP checksum offload. > In that case, for FVL he has 2 choices: > 1. Treat that packet as a 'proper' tunnelled packet, and fill all the fields: > mb->l2_len = eth_hdr_in; > mb->l3_len = ipv4_hdr_in; > mb->outer_l2_len = eth_hdr_out; > mb->outer_l3_len = ipv4_hdr_out; > mb->l4tun_len = vxlan_hdr; > mb->ol_flags |= PKT_TX_UDP_TUNNEL_PKT | PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM; > > 2. As user doesn't care about outer IP hdr checksum, he can treat everything before ipv4_hdr_in as L2 header. > So he knows, that it is a tunnelled packet, but makes HW to treat it as ordinary (non-tunnelled) packet: > mb->l2_len = eth_hdr_out + ipv4_hdr_out + udp_hdr_out + vxlan_hdr + ehtr_hdr_in; > mb->l3_len = ipv4_hdr_in; > mb->ol_flags |= PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM; > > i40e PMD will support both B.1 and B.2. > ixgbe/igb/em PMD supports only B.2. > if HW supports both - it will be up to user app which method to choose. I think we should have a flag to advertise outer ip and outer udp checksum offload support, so the application knows which mode can be used. Regards, Olivier