From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from unknown [12.187.104.26] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 380c7485.2b9fe0666940.234183.00-2485.483582.nbfkord-smmo01.seg.att.com (envelope-from ); Wed, 07 Dec 2016 07:55:47 +0000 (UTC) X-MXL-Hash: 5847c0836834325e-4b281be63742d97fbd5aab470e444d1d847f875f Received: from unknown [12.187.104.26] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id f70c7485.0.234179.00-2395.483566.nbfkord-smmo01.seg.att.com (envelope-from ); Wed, 07 Dec 2016 07:55:46 +0000 (UTC) X-MXL-Hash: 5847c08261182c4e-8b352d6ef5db2e2de865d2a65631ecdf25e736c4 Received: from [192.168.38.17] (84.52.89.52) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 6 Dec 2016 23:55:37 -0800 To: Ferruh Yigit , Thomas Monjalon , , Jan Medala , Jakub Palider , Netanel Belgazal , Evgeny Schemeilin , Alejandro Lucero , Yuanhan Liu , Yong Wang , Hemant Agrawal 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> CC: Tomasz Kulasek , From: Andrew Rybchenko Message-ID: <854d0b4b-88ae-d5ef-dd02-3bb6ebd473c3@solarflare.com> Date: Wed, 7 Dec 2016 10:55:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com> X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-AnalysisOut: [v=2.1 cv=I8xjMYUg c=1 sm=1 tr=0 a=8BlWFWvVlq5taO8ncb8nKg==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=n5n_aSjo0skA:10 a=8rWy6zfcAAAA:8 a] X-AnalysisOut: [=Fr6QqUtPLiosTsUZvNAA:9 a=LVPjKocuRGbT9nEN:21 a=cepg-lCfer] X-AnalysisOut: [vWrSwV:21 a=pILNOxqGKmIA:10 a=QyXUC8HyAAAA:8 a=Jg2-Gn5M2hy] X-AnalysisOut: [i8xAvihIA:9 a=AoPgNwb67XXI8BFT:21 a=-S97XV8Tya_CB0_u:21 a=] X-AnalysisOut: [deR10dbRrGMDKY1U:21 a=_W_S_7VecoQA:10 a=YjdVzJdQTyZRADMV7w] X-AnalysisOut: [FX:22 a=avl4LiGQNoF5OB0DmCJ7:22] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [12.187.104.26] Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 07:55:47 -0000 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