From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John Daley (johndale)" Subject: Re: [PATCH v12 0/6] add Tx preparation Date: Wed, 30 Nov 2016 05:48:36 +0000 Message-ID: <8cd623e5433d44cb89b9599f6a60d5cd@XCH-RCD-007.cisco.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Tomasz Kulasek , "konstantin.ananyev@intel.com" , "olivier.matz@6wind.com" To: Thomas Monjalon , "dev@dpdk.org" , Rahul Lakkireddy , Stephen Hurd , Jan Medala , Jakub Palider , Adrien Mazarguil , "Alejandro Lucero" , Harish Patil , Rasesh Mody , Jerin Jacob , Yuanhan Liu , Yong Wang Return-path: Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by dpdk.org (Postfix) with ESMTP id 86E772BCD for ; Wed, 30 Nov 2016 06:48:47 +0100 (CET) In-Reply-To: <8317180.L80Qf11uiu@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, -john > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, November 28, 2016 3:03 AM > To: dev@dpdk.org; Rahul Lakkireddy ; > Stephen Hurd ; Jan Medala > ; Jakub Palider ; John Daley > (johndale) ; 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 > Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation >=20 > We need attention of every PMD developers on this thread. >=20 > 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 t= o: > * 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. > " >=20 > I copy/paste also my previous conclusion: >=20 > 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? >=20 > 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. >=20 > git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' > drivers/net/ >=20 > 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 >=20 > Please, we need a comment for each driver saying "it is OK, we do not nee= d > any checksum preparation for TSO" > or > "yes we have to implement tx_prepare or TSO will not work in this mode" I like the idea of tx prep since it should make for cleaner apps. For enic, I believe the answer is " it is OK, we do not need any checksum p= reparation". Prior to now, it was necessary to set IP checksum to 0 and put in a TCP/UDP= pseudo header. But there is a hardware overwrite of checksums option which= makes preparation in software unnecessary and it is testing out well so fa= r. I plan to enable it in 17.02. TSO is also being enabled for 17.02 and it= does not look like any prep is required. So I'm going with " txprep NULL p= ointer is OK for enic", but may have to change my mind if something comes u= p in testing. -john