From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 171505582 for ; Wed, 30 Nov 2016 11:59:12 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP; 30 Nov 2016 02:59:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,573,1473145200"; d="scan'208";a="11535313" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga002.jf.intel.com with ESMTP; 30 Nov 2016 02:59:09 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX153.ger.corp.intel.com ([169.254.9.203]) with mapi id 14.03.0248.002; Wed, 30 Nov 2016 10:59:08 +0000 From: "Ananyev, Konstantin" To: "John Daley (johndale)" , 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 CC: "Kulasek, TomaszX" , "olivier.matz@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v12 0/6] add Tx preparation Thread-Index: AQHSRbBDKacvBhx2eUCvrHI7LRX1L6DuQp0AgALMywCAAFZF0A== Date: Wed, 30 Nov 2016 10:59:08 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0E20F6@irsmsx105.ger.corp.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> <8cd623e5433d44cb89b9599f6a60d5cd@XCH-RCD-007.cisco.com> In-Reply-To: <8cd623e5433d44cb89b9599f6a60d5cd@XCH-RCD-007.cisco.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 10:59:13 -0000 Hi John, >=20 > Hi, > -john >=20 > > -----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 > > > > 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 wou= ld > > implement expected modifications of the packet contents and restriction > > checks. > > Otherwise, tx_prep() implementation is not required and can be safely s= et 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 n= eed > > any checksum preparation for TSO" > > or > > "yes we have to implement tx_prepare or TSO will not work in this mode" >=20 > I like the idea of tx prep since it should make for cleaner apps. >=20 > For enic, I believe the answer is " it is OK, we do not need any checksum= preparation". >=20 > Prior to now, it was necessary to set IP checksum to 0 and put in a TCP/U= DP pseudo header. But there is a hardware overwrite of > checksums option which makes preparation in software unnecessary and it i= s testing out well so far. 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. S= o I'm going with " txprep NULL pointer is OK for enic", but may have > to change my mind if something comes up in testing. That's great thanks. Other non-Intel PMD maintainers, please any feedback?=20 Konstantin >=20 > -john