From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id D976E2BF6
 for <dev@dpdk.org>; Tue,  6 Dec 2016 16:53:47 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga105.jf.intel.com with ESMTP; 06 Dec 2016 07:53:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="14384676"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29])
 ([10.237.220.29])
 by orsmga002.jf.intel.com with ESMTP; 06 Dec 2016 07:53:43 -0800
To: Thomas Monjalon <thomas.monjalon@6wind.com>, dev@dpdk.org,
 Jan Medala <jan@semihalf.com>, Jakub Palider <jpa@semihalf.com>,
 Netanel Belgazal <netanel@amazon.com>, Evgeny Schemeilin
 <evgenys@amazon.com>, Alejandro Lucero <alejandro.lucero@netronome.com>,
 Yuanhan Liu <yuanhan.liu@linux.intel.com>, Yong Wang <yongwang@vmware.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>
References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com>
 <1479922585-8640-1-git-send-email-tomaszx.kulasek@intel.com>
 <8317180.L80Qf11uiu@xps13>
Cc: Tomasz Kulasek <tomaszx.kulasek@intel.com>, konstantin.ananyev@intel.com
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com>
Date: Tue, 6 Dec 2016 15:53:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <8317180.L80Qf11uiu@xps13>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 15:53:48 -0000

On 11/28/2016 11:03 AM, Thomas Monjalon wrote:
> 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"
>

Still waiting response from PMDs:
- ena
- nfp
- virtio

Waiting clarification for preparation requirements:
- vmxnet3

Also including new PMDs to the thread:
- sfc
- dpaa2