From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id D0C661B6A6 for ; Tue, 30 Jan 2018 21:22:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3660A216FE; Tue, 30 Jan 2018 15:22:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 30 Jan 2018 15:22:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=pqNFTl8XfkhvaJ6sHig2HRId/0 3VeqbNchihbHCdUBE=; b=f4myREdLETxOSoqNfkjVc8WNwqoNjAOJJo64YgOnQ5 cO2pWEPHswo9y7YayK5Y7Jfu67MroDpBPvYVQHIjjuswaAlQPu2uywfE5lKZi3WX YxT1NB9/ihVN2Puxafs6PzVPJzuoPeTqm8obQBh767UIrxAdmLCttEORY1NvGH2c c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pqNFTl 8XfkhvaJ6sHig2HRId/03VeqbNchihbHCdUBE=; b=aVB+5Ai1XtqSfLQW3zJvg3 6UP7+OxYu755y9DUHj6jEVHDQ7D3LsDlG7kz0enqTy5/UO/11qvsjj0hwXsiv+Xz oILvHQWIDkjxtiR0Au3OBUDM1+oojKo5IS2MGoEtbM0hV767Wntu5ER7X5aq2ftZ IHtGSj8u1VLFZ+EZQ6Fv0kfoz7cwBL7DW9clT/8ZKHV8+mBCrbCEtAVuccbjKG4z EQ4LeEYabAU7vuw91Ao/J0nLlCJxIMXzZCBBk7La1wUwmoUGCNGGoJAr7PAxYK/d Ic6tpGxXe7+bkHRleaWuHYkZULPLB/X4keaRfKGER1H9ZksZX44J0p4hZlkENTvA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CB5E224800; Tue, 30 Jan 2018 15:22:06 -0500 (EST) From: Thomas Monjalon To: "Xueming(Steven) Li" Cc: "Ananyev, Konstantin" , Olivier MATZ , dev@dpdk.org, "Wu, Jingjing" , Shahaf Shuler , Yongseok Koh , "Yigit, Ferruh" Date: Tue, 30 Jan 2018 21:21:20 +0100 Message-ID: <3030421.JaM4VfFdR3@xps> In-Reply-To: References: <20180109141110.146250-2-xuemingl@mellanox.com> <2601191342CEEE43887BDE71AB97725890565D01@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic 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: Tue, 30 Jan 2018 20:22:08 -0000 Xueming, We already discussed privately some time ago about this API. You got some questions from me, from Olivier and from Konstantin. The next version should answer the questions asked. When defining an API, the doxygen documentation must explain precisely what must be set, when and why. The documentation must be sufficient to allow users using it, and to allow PMD writers to implement it. I think it cannot be properly reviewed until we clearly understand the API and the HW requirements/expectations. Hope this helps to understand what is expected for integrating such API. 30/01/2018 18:54, Xueming(Steven) Li: > > > > > > > > > > > This patch introduce new TX offloads flag for devices > > > > > > > > > > > that support tunnel agnostic checksum and TSO offloads. > > > > > > > > > > > > > > > > > > > > > > The support from the device is for inner and outer > > > > > > > > > > > checksums on IPV4/TCP/UDP and TSO for *any packet with > > > > > > > > > > > the following > > > > > > format*: > > > > > > > > > > > > > > > > > > > > > > < some headers > / [optional IPv4/IPv6] / [optional > > > > > > > > > > > TCP/UDP] / > > > > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional > > > > > > > > > > > headers> TCP/UDP] > > > > > > > > > > > > > > > > > > > > > > For example the following packets can use this feature: > > > > > > > > > > > > > > > > > > > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / > > > > > > > > > > > GRE / MPLS / > > > > > > > > > > > ipv4 / udp > > > > > > > > > > > > > > > > > > > > So in terms of usage - what is the difference with > > > > > > > > > > current TSO > > > > > > types? > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > > > > > > > > Traditionally, HW only recognize "known" tunnel type, do > > > > > > > > > TSO calculation based on L3/L4 headers known to tunnel > > > > > > > > > type. For example, it must be > > > > > > > > > L2 header after VXLAN, then L3. While this Generic > > > > > > > > > offloading provides inner/outer L3/L4 header info(len and > > > > > > > > > offset) to HW, and thus tunnel info become less important. > > > > > > > > > Please note the MPLS over GRE tunnel in last example above. > > > > > > > > > > > > > > > > Ok, but I wonder when the user would like to do TSO on > > > > > > > > tunnel packet, for this offload - would he need to do > > > > > > > > something differently from what he has to do now: > > > > > > > > raise PKT_TX_TCP_SEG and related flags, raise appropriate > > > > > > > > PKT_TX_TUNNEL_* flag, fill l2_len, l3_len, > > > > > > l4_len,tso_segsz,outer_l2_len,outer_l3_len? > > > > > > > > > > > > > > > > > > > > > > Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major > > > > > > > target of this new feature is to support "unknown" tunnel > > > > > > > offloading, it > > > > > > supports "known" > > > > > > > tunnel type as well. > > > > > > > > > > > > Ok, but user would still need to set some flag to indicate that > > > > > > this is a tunnel packet, and he wants TSO over it, right? > > > > > > For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_* > > > > > > (which actually means that user still have to know tunnel type > > > > > > anyway?) But for some not defined tunnel type - what it would be? > > > > > > Konstantin > > > > > > > > > > > > > > > > As this feature target to TX path, Outer length as tunnel > > > > > indication, leave it empty if tunnel not defined. > > > > > > > > Sorry, I didn't get it. > > > > We need to let PMD know that it is a tunnel packet, right? > > > > So we do need to raise PKT_TX_TUNNEL_* flag. > > > > > > > > > > In my current code, mbuf.outer_l2_len is used to test tunnel packet. > > > Agree a new tunnel flag would be better. > > > > > > > > > > > > > But I think it good to define something like: > > > > > PKT_TX_TUNNEL_GENERIC = PKT_TX_TUNNEL_MASK > > > > > > > > Yes, that's an option, I would probably name it PKT_TX_TUNNEL_UNKNOWN. > > > > > > > > > And a new flag PKT_TX_OUTER_UDP, how do you think? > > > > > > > > Not sure why do we need it? > > > > HW still needs to know outer_l4_type to be able to work correctly? > > > > > > For tunnel type like vxlan, if outer UDP present, hw has to update UDP > > > length field for each TSO packet segment. > > > > I understand that, but I thought that HW is smart enough to parse the > > header and recognize outer L3/L4 type - as it is a 'generic' tunneling > > (sorry I am not familiar with MLX HW at all). > > It might be useful if the outer encapsulation not regular, for example MPLS. > > > From what you saying - that assumption was wrong and user still need to > > provide some packet-type info at least about outer headers, right? > > So what else need to be set? > > Probably PKT_TX_OUTER_IPV*, might be something else? > > Sorry for the confusion, besides optional outer UDP type, still need PKT_TX_IPV4/6 and PKT_TX_OUTER_IPV4/6