From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 3EF3C3772 for ; Mon, 22 Jan 2018 13:46:47 +0100 (CET) Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1edbUs-0006bK-Kq; Mon, 22 Jan 2018 13:46:48 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 22 Jan 2018 13:46:38 +0100 Date: Mon, 22 Jan 2018 13:46:38 +0100 From: Olivier Matz To: Shahaf Shuler Cc: "Xueming(Steven) Li" , Thomas Monjalon , Jingjing Wu , Yongseok Koh , "dev@dpdk.org" Message-ID: <20180122124638.pybfffk4iqjohouy@platinum> References: <20180109141110.146250-1-xuemingl@mellanox.com> <20180109141110.146250-5-xuemingl@mellanox.com> <20180116171010.vt25o6uq3kb7cpzd@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH 4/6] ethdev: introduce TX common tunnel offloads 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: Mon, 22 Jan 2018 12:46:47 -0000 Hi, On Tue, Jan 16, 2018 at 07:06:15PM +0000, Shahaf Shuler wrote: > Hi Oliver, Xueming, > > Tuesday, January 16, 2018 7:29 PM, Xueming(Steven) Li: > > > Hi Xueming, > > > > > > On Tue, Jan 09, 2018 at 10:11:08PM +0800, Xueming Li wrote: > > > > */ > > > > #define DEV_TX_OFFLOAD_SECURITY 0x00020000 > > > > +/**< Device supports arbitrary tunnel chksum and tso offloading w/o > > > knowing > > > > + * tunnel detail. Checksum and TSO are calculated based on mbuf > > > fields: > > > > + * l*_len, outer_l*_len > > > > + * PKT_TX_OUTER_IPV6, PKT_TX_IPV6 > > > > + * PKT_TX_IP_CKSUM, PKT_TX_TCP_CKSUM, PKT_TX_UDP_CKSUM > > > > + * When set application must guarantee correct header fields, no need > > > to > > > > + * specify tunnel type PKT_TX_TUNNEL_* for HW. > > > > + */ > > I think some documentation is missing here. > What the NIC needs to know to support the generic tunnel TSO and checksum offloads is: > 1. the length of each header > 2. the type of the outer/inner l3/l4. Meaning is it IPv4/IPv6 and whether it is UDP/TCP. > > The outer IPv6 seems covered. The inner L4 seems missing. > > More details about this offload below. > > > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x00040000 > > > > > > > > struct rte_pci_device; > > > > > > > > > > I'd like to have more details about this flag and its meaning. > > > > > > Let's say we want to do TSO on the following vxlan packet: > > > Ether / IP1 / UDP / VXLAN / Ether / IP2 / TCP / Data > > > > > > With the current API, we need to pass the tunnel type to the hardware > > > with the flag PKT_TX_TUNNEL_VXLAN. Thanks to that, the driver can > > > forward this information to the hardware so it knows that the > > > ip1->length, udp->length and optionally the udp->chksum have to be > > > updated for each generated segment. > > > > > > With your proposal, if I understand properly, it is not expected to > > > pass the tunnel type in the mbuf. So how can the hardware know if some > > > fields have to be updated in the outer header? > > > > I'm not expert on hardware, the driver has to supply outer and inner > > L3/L4 offsets, types and which field(s) to fill checksum, no length update as > > far as I know. > > Mellanox HW is capable to parse the packet according to hints from the driver. > > If you think about it, to calculate the IP checksum all you need to do is know the inner/outer IP offset, and the fact it is an IPv4. > To calculate the inner TCP/UDP checksum it is the same. all that after the L4 is counted as payload and the pseudo header can be done with the information about the IP. > > About TSO - just need to get the offset till the inner header so that the NIC can append the full headers to every segment and update the inner/outer L3 and L4 fields accordingly (which their location is known). I think that's partially true. Let me try to clarify: - in case of VXLAN (my previous example), the hw needs to update the outer L3 (ip length) and L4 (udp length and optionnally checksum) - in case of GRE, an update of the checksum is required if present. The sequence number may also be increased (I don't know how widely it is used). - in case of a proprietary or unsupported tunnel, the hardware cannot know which fields to update in the outer header. So I'm not sure a "generic" flag is possible. How can the application know which tunnels types are supported by the hardware and which should be done in software? Olivier