From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Rybchenko Subject: Re: [PATCH v12 0/6] add Tx preparation Date: Wed, 7 Dec 2016 10:55:34 +0300 Message-ID: <854d0b4b-88ae-d5ef-dd02-3bb6ebd473c3@solarflare.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"; format=flowed Content-Transfer-Encoding: 7bit Cc: Tomasz Kulasek , To: Ferruh Yigit , Thomas Monjalon , , Jan Medala , Jakub Palider , Netanel Belgazal , Evgeny Schemeilin , Alejandro Lucero , Yuanhan Liu , Yong Wang , Hemant Agrawal Return-path: Received: from nbfkord-smmo01.seg.att.com (nbfkord-smmo01.seg.att.com [209.65.160.76]) by dpdk.org (Postfix) with ESMTP id 6715E2BAF for ; Wed, 7 Dec 2016 08:55:47 +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/06/2016 06: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 The patch which adds TSO support is http://dpdk.org/dev/patchwork/patch/17417/ We use l2/l3/l4 header length. We do NOT use prepared pseudo header checksum and HW does NOT need it. Andrew. > - dpaa2