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 0A2B25F2C for ; Thu, 31 May 2018 20:27:25 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2018 11:27:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,463,1520924400"; d="scan'208";a="59320679" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 31 May 2018 11:27:22 -0700 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 31 May 2018 11:27:22 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.220]) by fmsmsx124.amr.corp.intel.com ([169.254.8.177]) with mapi id 14.03.0319.002; Thu, 31 May 2018 11:27:21 -0700 From: "Wiles, Keith" To: Moti Haimovsky CC: "adrien.mazarguil@6wind.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] net/mlx4: add TSO support Thread-Index: AQHT+PuJNHAUobxzBU2OhS6TLyCXJ6RKnWcA Date: Thu, 31 May 2018 18:27:21 +0000 Message-ID: References: <1527783686-1727-1-git-send-email-motih@mellanox.com> In-Reply-To: <1527783686-1727-1-git-send-email-motih@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.100.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <97808649B7B5B949BA3477E151422A60@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] net/mlx4: add TSO support 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: Thu, 31 May 2018 18:27:26 -0000 > On May 31, 2018, at 11:21 AM, Moti Haimovsky wrote: >=20 > TCP Segmentation Offload (TSO) is a feature which enables the TCP/IP > network stack to delegate segmentation of a TCP segment to the NIC, > thus saving compute resources. >=20 > This RFC proposes to add support for TSO to the MLX4 PMD. >=20 > Prerequisites: > In order for the PMD to recognize the TSO capabilities of the device > one has to use: > * RDMA-core v18.0 or above. > * Linux kernel 4.16 or above. >=20 > Assumptions: > * mlx4 PMD will follow the TSO support implemented in mlx5 PMD.=20 > * PMD is backwards compatible. > ** The PMD will continue work with the kernels and RDMA-core > supported by it today. > ** The PMD will continue to work with devices not supporting TSO.=20 >=20 > Changes proposed in the PMD for implementing TSO: > * At init, query the device for TSO support and MAX segment size > being supported. > This will also determine if the PMD will advertise support for TSO > (dev_info->tx_offload_capa |=3D DEV_TX_OFFLOAD_TCP_TSO;) > * Calling create-qp when creating a Tx queue will have to consider > the MAX TSO header size when calculating the actual queue buffer > size. This may be abstracted by calling ibv_create_qp_ex with > IBV_QP_INIT_ATTR_MAX_TSO_HEADER as comp flag rather than > ibv_create_qp. > If this breaks backwards compatibility then this calculation will > be done in the PMD code. > * Modify tx_burst function to: > ** Check for TSO flag indication in the packets of the packet burst > (buf->ol_flags & PKT_TX_TCP_SEG). > ** For TSO packet create the WQE appropriate for sending a TSO packet > and fill it with packet info and L2/L3/L4 Headers. > * Modify Tx completion function to handle releasing of TSO packet > buffers that were transmitted. >=20 > Concerns: > * Impact of changing Tx send routine on performance. > The performance of the tx_burst routine for non-TSO packets may be > affected just by placing the code that handles TSO packets in it, > so we may want to consider having a dedicated routine for TSO packets. How much shared code between the two APIs if we created a new API just for = TSO? My first thought was to create a new API, but it would require my applicati= on to know it needs to call the new TSO API instead of the normal tx_burst = API or does it? Maybe it does not matter and a TSO request would never be directed to the n= ormal API, if that is the case I would like a new API and not effect the ol= d one.=20 > * No MAX-TSO parameter. > This is a cross-PMD issue that may need a separate mailing thread to ha= ndle. > As for today there is no way for the PMD to advertise the MAX-TSO > it or its HW support as done with other capabilities. > (The indirection table size for example. > see rte_eth_dev_info.reta_size in rte_ethdev.h). > Also there is no DPDK parameter or constant value that the PMD > can use in order to know the MAX-TSO the system requires. > This prevents applications from determining the MAX-TSO that can be > used leading to configuration mismatches that may lead to transmit > failures or to less-than-optimize TSO configuration in the best case. > I propose to add a max_tso field in rte_eth_dev_info that will allow > the PMD to advertise the max tso is supports. This can be used by > DPDK applications to determine what TSO size to use. > If this is a major change that cannot fit the 18.08 schedule then > I propose to add a MAX_TSO constant in rte_ethdev.h, The PMD will > compare this value whit its own MAX-TSO and if it cannot meet the > defined value it will not advertise that it is a TSO capable device. > * Handling packets longer then MAX-TSO > In case a PMD is requested to send a TSO packet which is longer than > MAX-TSO the PMD send routine should return with an error. > A different approach that can be used on the future is to apply GSO > to those packets using the GSO lib in DPDK. >=20 > I am interested in general design comments and concerns listed above. >=20 > Signed-off-by: Moti Haimovsky >=20 > --=20 > 1.8.3.1 >=20 Regards, Keith