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 34F682BB1 for ; Fri, 23 Dec 2016 19:49:34 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 23 Dec 2016 10:49:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,395,1477983600"; d="scan'208";a="45907940" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga005.jf.intel.com with ESMTP; 23 Dec 2016 10:49:32 -0800 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 23 Dec 2016 18:49:31 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.230]) by irsmsx112.ger.corp.intel.com ([169.254.1.175]) with mapi id 14.03.0248.002; Fri, 23 Dec 2016 18:49:31 +0000 From: "Kulasek, TomaszX" To: Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v14 1/8] ethdev: add Tx preparation Thread-Index: AQHSXFQ0+2tVXThBuEq+L0VC9Y9ZR6EUBZoAgAHVJhA= Date: Fri, 23 Dec 2016 18:49:31 +0000 Message-ID: <3042915272161B4EB253DA4D77EB373A14F6E612@IRSMSX102.ger.corp.intel.com> References: <1481650914-40324-1-git-send-email-tomaszx.kulasek@intel.com> <1482411919-7620-1-git-send-email-tomaszx.kulasek@intel.com> <1482411919-7620-2-git-send-email-tomaszx.kulasek@intel.com> <5890222.TpSixoQlLd@xps13> In-Reply-To: <5890222.TpSixoQlLd@xps13> Accept-Language: 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 v14 1/8] ethdev: 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: Fri, 23 Dec 2016 18:49:34 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, December 22, 2016 15:25 > To: Kulasek, TomaszX > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v14 1/8] ethdev: add Tx preparation >=20 > Hi Tomasz, >=20 > 2016-12-22 14:05, Tomasz Kulasek: > > Added API for `rte_eth_tx_prepare` > > > > uint16_t rte_eth_tx_prepare(uint8_t port_id, uint16_t queue_id, > > struct rte_mbuf **tx_pkts, uint16_t nb_pkts) >=20 > As discussed earlier and agreed by Konstantin, please mark this API > as experimental. > We could make some changes in 17.05 to improve error description > or add some flags to modify the behaviour. >=20 Is it enough to add /** * @warning * @b EXPERIMENTAL: this API may change without prior notice ? >=20 > > int rte_net_intel_cksum_prepare(struct rte_mbuf *m) > > > > to prepare pseudo header checksum for TSO and non-TSO tcp/udp packets > > before hardware tx checksum offload. > > - for non-TSO tcp/udp packets full pseudo-header checksum is > > counted and set. > > - for TSO the IP payload length is not included. > > > > > > int > > rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags= ) > > > > this function uses same logic as rte_net_intel_cksum_prepare, but > > allows application to choose which offloads should be taken into > > account, if full preparation is not required. >=20 > How the application knows which offload flag should be taken into account= ? > This new API is used in ena driver: + /* ENA doesn't need different phdr cskum for TSO */ + ret =3D rte_net_intel_cksum_flags_prepare(m, + ol_flags & ~PKT_TX_TCP_SEG); + if (ret !=3D 0) { + rte_errno =3D ret; + return i; + } It's more useful to mask offloads which didn't should be used.=20 >=20 > > # > > +# Use real NOOP to turn off TX preparation stage > > +# > > +# While the behaviour of ``rte_ethdev_tx_prepare`` may change after > turning on > > +# real NOOP, this configuration shouldn't be never enabled globaly, an= d > can be > > +# used in appropriate target configuration file with a following > restrictions > > +# > > +CONFIG_RTE_ETHDEV_TX_PREPARE_NOOP=3Dn >=20 > As discussed earlier, it would be easier to not call tx_prepare at all. > However, this option allows an optimization when compiling DPDK for a > known environment without modifying the application. > So it is worth to keep it. >=20 > The text explaining the option should be improved. > I suggest this text: >=20 > # Turn off Tx preparation stage > # > # Warning: rte_ethdev_tx_prepare() can be safely disabled only if using a > # driver which do not implement any Tx preparation. >=20 >=20 > > + uint16_t nb_seg_max; /**< Max number of segments per whole packet. > */ > > + uint16_t nb_mtu_seg_max; /**< Max number of segments per one MTU */ >=20 > In another mail, you've added this explanation: > * For non-TSO packet, a single transmit packet may span up to > "nb_mtu_seg_max" buffers. > * For TSO packet the total number of data descriptors is "nb_seg_max", an= d > each segment within the TSO may span up to "nb_mtu_seg_max". >=20 > Maybe you can try to mix these comments to improve the doxygen. Ok, I will. Tomasz