From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 3E4B368CD for ; Wed, 3 Dec 2014 12:45:23 +0100 (CET) Received: by mail-wi0-f177.google.com with SMTP id l15so24094098wiw.4 for ; Wed, 03 Dec 2014 03:45:23 -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=ff6OTHL5+Zhk2vNHBggFgPgoc7R/cqqRRTmt3YIlwms=; b=H//fJ9Ik4tQ0r6XWEd/CzIXVl1T6lRZwkBdIzoDyo2iufJijlKjJEA6if2ppWYQe0v gO57KTczRnybFJLmdQJH+i5hOplXBqr12wnuVmXF5ank3wffovjOGtX4O/9aVJa06A7j l7wLQlcwctgrPzV9nTOYw1SWBEMV6aLrzIVUXDLuNoo/pjrpy9HwWGZ/UmQRX/yILKyy wYlw3BgrzeFtcKwgMaQaYA0L96t7jRKXhPmUxWB4P6VLsrCG5xkiT8fov7q8AdkP9gEl pK5d3DYwQ5VS+EPpwXItQGyy+qQ67rqn3BPIALCncpkLv9wefpg2AmH80lCS3O5NmCfS Bgug== X-Gm-Message-State: ALoCoQl2pPoeBlCKsdPGXfPd93MHwjcGU3VTlXpz23flm3Fxhc8sO3WUtYXpThDxNRYrS3f39yl2 X-Received: by 10.194.179.166 with SMTP id dh6mr2555981wjc.87.1417607123123; Wed, 03 Dec 2014 03:45:23 -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 l3sm35939458wje.12.2014.12.03.03.45.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 03:45:22 -0800 (PST) Message-ID: <547EF7D1.40505@6wind.com> Date: Wed, 03 Dec 2014 12:45:21 +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: <1417532767-1309-1-git-send-email-jijiang.liu@intel.com> <1417532767-1309-4-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1417532767-1309-4-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 v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields 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, 03 Dec 2014 11:45:23 -0000 Hi Jijiang, On 12/02/2014 04:06 PM, Jijiang Liu wrote: > Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len field, and rework csum forward engine and i40e PMD due to these changes. > > Signed-off-by: Jijiang Liu > --- > app/test-pmd/csumonly.c | 58 +++++++++++++++++++++------------------ > lib/librte_mbuf/rte_mbuf.h | 4 +- > lib/librte_pmd_i40e/i40e_rxtx.c | 38 +++++++++++++------------ > 3 files changed, 53 insertions(+), 47 deletions(-) > One more thing about the arguments of testpmd, thay may be changed a bit to make it clearer. We may also remove the distinction between udp/tcp/sctp and just have l4 instead. We don't need to add a tunnel-type argument in the testpmd command line, because the application is already able to parse the packet and can set the proper tunnel flag by itself. This is the current description of the csumonly forward engine: * Receive a burst of packets, and for each packet: * - parse packet, and try to recognize a supported packet type (1) * - if it's not a supported packet type, don't touch the packet, else: * - modify the IPs in inner headers and in outer headers if any * - reprocess the checksum of all supported layers. This is done in SW * or HW, depending on testpmd command line configuration * - if TSO is enabled in testpmd command line, also flag the mbuf for * TCP segmentation offload (this implies HW TCP checksum) * Then transmit packets on the output port. * * (1) Supported packets are: * Ether / (vlan) / IP|IP6 / UDP|TCP|SCTP . * Ether / (vlan) / outer IP|IP6 / outer UDP / VxLAN / Ether / IP|IP6 * / UDP|TCP|SCTP * * The testpmd command line for this forward engine sets the flags * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control * wether a checksum must be calculated in software or in hardware. The * IP, UDP, TCP and SCTP flags always concern the inner layer. The * VxLAN flag concerns the outer IP and UDP layer (if packet is * recognized as a vxlan packet). This would give: tx_cksum set (outer-ip|outer-l4|ip|l4) (hw|sw) (port_id) A/ outer-ip=sw, outer-l4=sw, ip=sw, l4=sw Ether / IP / UDP IP, UDP checksum reprocessed in sw Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2: IP1, UDP1, IP2, UDP2 checksums reprocessed in sw B/ outer-ip=hw, outer-l4=hw, ip=sw, l4=sw Ether / IP / UDP IP, UDP checksum reprocessed in sw Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2: IP1, UDP1 checksums reprocessed in hw (using l2_len, l3_len) IP2, UDP2 checksums reprocessed in sw C/ outer-ip=hw, outer-l4=hw, ip=hw, l4=hw Ether / IP / UDP IP, UDP checksum reprocessed in hw (using l2_len, l3_len) Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2: IP1 checksums reprocessed in hw (using outer_l2_len, outer_l3_len) UDP1 checksum must be 0 in packet (I think it's not supported by hw or driver today) IP2, UDP2 checksums reprocessed in hw (using l2_len, l3_len) D/ outer-ip=sw, outer-l4=sw, ip=hw, l4=hw Ether / IP / UDP IP, UDP checksum reprocessed in hw (using l2_len and l3_len) Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2: not supported, we are not able to calculate the outer checksum in sw as some inner fields will be filled by the hw What is your opinion? Regards, Olivier