From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f174.google.com (mail-wj0-f174.google.com [209.85.210.174]) by dpdk.org (Postfix) with ESMTP id E99AA2C55 for ; Mon, 28 Nov 2016 12:03:08 +0100 (CET) Received: by mail-wj0-f174.google.com with SMTP id v7so112313833wjy.2 for ; Mon, 28 Nov 2016 03:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=uZXqyuvaJXj1Z/+n2EkPNvvEdfqpksFNM6Vs5cGHZlw=; b=xPPvmxvsfdHVZ69AMf1SnTrVcwTH2lfm+3xqNttupcuDWmHPjVFZaBK9vYukA13/qa Z09UjDNqe7O5/x2+ReYXYdJFmbZsaqxRUFOCsD6EtIWmPA2d1UO0TINQCeVLAdJK9mTk Q+Uv6NxB9L8eIikVXLhNpDZuXfEbRf5CAFrpCUizuJWGi9l1f8L8VdRRw5g1I+98GBly u/DHX5hTFQbBy5Islufw/hnX99TFfhBFEzMsIJxNmwO7J3U+znZT58ewGEqfCTxxQlSN o19NXNwkjBqsKEfUF4sQfPxmOtm5K83tOEgOu1MQAjPmhArqRdPnMdfwKbeqb1zfv4QT yUhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=uZXqyuvaJXj1Z/+n2EkPNvvEdfqpksFNM6Vs5cGHZlw=; b=IcTwMlVS3eJmaNkC9V9WgdqRFW0baTbRjjaHAsg1niTCVbziuYUCieJiyjaWLPXHEn tBW2Nvn69fOAySCs9JEIYri/nolUrlks0dHIdQy2MmsD7IPDVLpX+yNDRPfDqzesRWV3 YeVJrwEl+bshL4Xpc+mjWTqaMmIiFeSxhUfVn6g+9Z/LjEC3hxrsfTDQ+Tv4ri4r4Khn Yg4NZsUVb1zaqVBh3b+xotww1r8hCh4wvKIhpruG8SCp5Gbl0rGVgc0xtjubzXWzgLBY YdODE+xiNFJ3QbKYB5mpUktDC1WMKQqHxFgQxsGdTXtS4+cxg+VHeLX2lmHbf9zBEHNI 0oFg== X-Gm-Message-State: AKaTC02DEhA3GfJ08VfDtnAevnFRpgkCwcxhXvD/3wFDdz7RxaT/WG2t2NcLV3sTYOP+zjUn X-Received: by 10.194.2.198 with SMTP id 6mr20997781wjw.51.1480330988684; Mon, 28 Nov 2016 03:03:08 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id c202sm33958490wme.1.2016.11.28.03.03.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 03:03:07 -0800 (PST) From: Thomas Monjalon To: dev@dpdk.org, Rahul Lakkireddy , Stephen Hurd , Jan Medala , Jakub Palider , John Daley , Adrien Mazarguil , Alejandro Lucero , Harish Patil , Rasesh Mody , Jerin Jacob , Yuanhan Liu , Yong Wang Cc: Tomasz Kulasek , konstantin.ananyev@intel.com, olivier.matz@6wind.com Date: Mon, 28 Nov 2016 12:03:06 +0100 Message-ID: <8317180.L80Qf11uiu@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1479922585-8640-1-git-send-email-tomaszx.kulasek@intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1479922585-8640-1-git-send-email-tomaszx.kulasek@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation 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: Mon, 28 Nov 2016 11:03:09 -0000 We need attention of every PMD developers on this thread. Reminder of what Konstantin suggested: " - if the PMD supports TX offloads AND - if to be able use any of these offloads the upper layer SW would have to: * modify the contents of the packet OR * obey HW specific restrictions then it is a PMD developer responsibility to provide tx_prep() that would implement expected modifications of the packet contents and restriction checks. Otherwise, tx_prep() implementation is not required and can be safely set to NULL. " I copy/paste also my previous conclusion: Before txprep, there is only one API: the application must prepare the packets checksum itself (get_psd_sum in testpmd). With txprep, the application have 2 choices: keep doing the job itself or call txprep which calls a PMD-specific function. The question is: does non-Intel drivers need a checksum preparation for TSO? Will it behave well if txprep does nothing in these drivers? When looking at the code, most of drivers handle the TSO flags. But it is hard to know whether they rely on the pseudo checksum or not. git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/ drivers/net/bnxt/bnxt_txr.c drivers/net/cxgbe/sge.c drivers/net/e1000/em_rxtx.c drivers/net/e1000/igb_rxtx.c drivers/net/ena/ena_ethdev.c drivers/net/enic/enic_rxtx.c drivers/net/fm10k/fm10k_rxtx.c drivers/net/i40e/i40e_rxtx.c drivers/net/ixgbe/ixgbe_rxtx.c drivers/net/mlx4/mlx4.c drivers/net/mlx5/mlx5_rxtx.c drivers/net/nfp/nfp_net.c drivers/net/qede/qede_rxtx.c drivers/net/thunderx/nicvf_rxtx.c drivers/net/virtio/virtio_rxtx.c drivers/net/vmxnet3/vmxnet3_rxtx.c Please, we need a comment for each driver saying "it is OK, we do not need any checksum preparation for TSO" or "yes we have to implement tx_prepare or TSO will not work in this mode"