From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v12 0/6] add Tx preparation Date: Tue, 13 Dec 2016 11:59:46 +0000 Message-ID: <1adecc1a-0738-8068-88e0-392684ea510d@intel.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> <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Tomasz Kulasek , konstantin.ananyev@intel.com To: Thomas Monjalon , dev@dpdk.org, Jan Medala , Jakub Palider , Netanel Belgazal , Evgeny Schemeilin , Yong Wang , Hemant Agrawal Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1C023370 for ; Tue, 13 Dec 2016 12:59:49 +0100 (CET) In-Reply-To: <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/6/2016 3:53 PM, Ferruh Yigit wrote: > 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 Thanks all for responses, now only remaining ones are following: Waiting clarification for preparation requirements: (it would be great if details can be provided before next version of the patch) - ena Will support review/testing of the patch: - vmxnet3 new PMD (still not in repo, so response is good to have) - dpaa2