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 6D29F1DB3; Tue, 24 Apr 2018 14:31:33 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 05:31:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,322,1520924400"; d="scan'208";a="44225506" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by FMSMGA003.fm.intel.com with ESMTP; 24 Apr 2018 05:31:29 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 24 Apr 2018 13:31:28 +0100 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.164]) by irsmsx111.ger.corp.intel.com ([169.254.2.167]) with mapi id 14.03.0319.002; Tue, 24 Apr 2018 13:31:28 +0100 From: "Ananyev, Konstantin" To: Ophir Munk , "Hu, Jiayu" , "dev@dpdk.org" CC: Thomas Monjalon , Olga Shern , Pascal Mazon , "stable@dpdk.org" Thread-Topic: [PATCH v1] gso: fix marking TCP checksum flag in TCP segments Thread-Index: AQHT2rl94CoPk27HYUCsaOLb2rnsLKQPm2oAgAAjyvD///4aAIAAGG2A Date: Tue, 24 Apr 2018 12:31:27 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258AEA5221E@IRSMSX102.ger.corp.intel.com> References: <1524406859-29585-1-git-send-email-ophirmu@mellanox.com> <2601191342CEEE43887BDE71AB977258AEA5081C@IRSMSX102.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWNmYzQwYmQtNDJkYy00YzhjLWFmY2MtOTU2NTVlZWVkNGFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImNQa3pyS3hCN3RiYnJLV2ZiWVl0NUpRZGczZkd5MlJ5ZGJzTWJoMkp4STg9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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-stable] [PATCH v1] gso: fix marking TCP checksum flag in TCP segments X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 12:31:34 -0000 Hi Ophir, >=20 > Hi Konstantin, > Please see inline >=20 > > -----Original Message----- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > > Sent: Tuesday, April 24, 2018 1:56 PM > > To: Ophir Munk ; Hu, Jiayu ; > > dev@dpdk.org > > Cc: Thomas Monjalon ; Olga Shern > > ; Pascal Mazon ; > > stable@dpdk.org > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP segme= nts > > > > > > > > > -----Original Message----- > > > From: Ophir Munk [mailto:ophirmu@mellanox.com] > > > Sent: Tuesday, April 24, 2018 10:44 AM > > > To: Hu, Jiayu ; dev@dpdk.org; Ananyev, Konstantin > > > > > > Cc: Thomas Monjalon ; Olga Shern > > > ; Pascal Mazon ; > > > stable@dpdk.org > > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > segments > > > > > > Hi Jiayu, > > > Please find comments inline > > > > > > > -----Original Message----- > > > > From: Hu, Jiayu [mailto:jiayu.hu@intel.com] > > > > Sent: Monday, April 23, 2018 7:14 AM > > > > To: Ophir Munk ; dev@dpdk.org; Ananyev, > > > > Konstantin > > > > Cc: Thomas Monjalon ; Olga Shern > > > > ; Pascal Mazon ; > > > > stable@dpdk.org > > > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > > segments > > > > > > > > Hi Ophir, > > > > > > > > In the GSO design, the GSO library doesn't care about checksums, > > > > which means it doesn't check if input packets have correct > > > > checksums, and it doesn't do any checksum related work for the > > > > output GSO segments. It depends on the callers to use HW or SW > > > > checksum calculation for output packets. This is why the GSO librar= y > > > > doesn't set PKT_TX_TCP_CKSUM. So I don't think it's a bug. > > > > > > > > > > Can you please reconsider this design? I think the GSO library should > > > imitate the HW behavior where TCP segments checksum is automatically > > > calculated without explicitly requesting it. I am not saying that GSO= library > > itself should calculate the checksums - but at least it should mark eac= h > > segment as requiring this calculation. > > > > But gso has no idea how this packet will be processed after it. >=20 > GSO shouldn't know. It should only mark the fact that a new TCP segment w= as created without a TCP checksum. >=20 Ok, but new IP header was also created. And might be outer ip/udp (in case = of tunnel). If we go that way we'll have to set flags for each them. > > Caller can choose to calculate L3/L4 cksum in SW or might be going to u= se > > HW offloads. >=20 > Assuming TSO is configured then you suggest that TAP PMD will mark by its= elf the TCP_CKSUM flag for all packets returned from GSO > library? Yes. >=20 > > In later case nothing stops the caller to update mbuf->ol_flags in a wa= y he > > likes (TCP_CKSUM, IP_CKSUM, etc.). > > Konstantin > > >=20 > Please note that TCP_SEG flag is cleared by GSO library in 2 different ca= ses: > 1. Packet length equals to or is bigger than GSO size. In this case new T= CP segments are created with no TCP checksum. > 2. Packet length is smaller than GSO size. In this case no TCP segmentati= on is required. The original packet is returned and its existing TCP > checksum is OK. >=20 > In the latter case TAP PMD will always calculate TCP checksum in SW (perf= ormance concerns) where this could have been saved. > I am thinking of a practical scenario where TSO is configured but all pac= kets are smaller than GSO size, however TAP PMD unnecessarily > recalculates their checksums. >=20 > How do you suggest to avoid this scenario? Probably something like that: rc =3D rte_gso_segment(pkt_in, gso_ctx, pkts_out, nb_pkts_out); if (rc =3D=3D 1 && pkt_in =3D=3D pkts_out[0] =3D=3D pkt_in) { /* no gso was performed */ } else { /* new packets, update ol_flags if needed */ } ? Another possibility - might be make chages in librte_gso to allow user to specify what flags to set for the output packets (probably via rte_gso_ctx= .flag)=20 Konstantin > > > > > > In my opinion, it's not a good idea to enable HW TCP checksum > > > > calculation silently, and without the aware of the caller. In fact, > > > > the caller always know it does SW TSO (i.e. GSO), instead of real H= W TSO. > > > > > > This is not correct. Consider net_failsafe with 2 sub-devices: one is > > > a HW PCI device, the other one is a SW TAP device. Failsafe must work > > transparently with these two sub-devices and the caller cannot tell if = TSO is > > done in SW or HW. > > > > > > > If the caller wants HW > > > > checksum calculation, it can add PKT_TX_TCP_CKSUM to ol_flags befor= e > > > > or after calling the GSO library. > > > > > > > > > > FYI - TAP TSO patches were submitted to dpdk.org mailing list. These > > patches use the GSO library. > > > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdp= d > > > > > k.org%2Fdev%2Fpatchwork%2Fpatch%2F38666%2F&data=3D02%7C01%7Coph > > irmu%40me > > > > > llanox.com%7C7455c8e31c7a4364bc7108d5a9d20008%7Ca652971c7d2e4d > > 9ba6a4d1 > > > > > 49256f461b%7C0%7C0%7C636601641779974217&sdata=3DCF7EvhXG%2BrH% > > 2BPiQEbvM0 > > > mC%2FSpqobneKaoV03j5VrSDw%3D&reserved=3D0 > > > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdp= d > > > > > k.org%2Fdev%2Fpatchwork%2Fpatch%2F38667%2F&data=3D02%7C01%7Coph > > irmu%40me > > > > > llanox.com%7C7455c8e31c7a4364bc7108d5a9d20008%7Ca652971c7d2e4d > > 9ba6a4d1 > > > > > 49256f461b%7C0%7C0%7C636601641779974217&sdata=3Dj9WVIj%2FKq6EN > > WXu3mr5By1 > > > toSowU8bqJRGZ19SxiGoI%3D&reserved=3D0 > > > > > > Running testpmd with TAP TSO is currently broken without the suggeste= d > > librte_gso patch. > > > Please note testpmd implementation (app/test-pmd/csumonly.c > > > b/app/test-pmd/csumonly.c) in case *both* TSO and TCP CKSUM are > > > configured: > > > > > > if (tso_segsz) > > > ol_flags |=3D PKT_TX_TCP_SEG; // *** if TSO is applicable - = the packet > > flags are only marked with PKT_TX_TCP_SEG and no > > > PKT_TX_TCP_CKSUM *** > > > else if (tx_offloads & DEV_TX_OFFLOAD_TCP_CKSUM) > > > ol_flags |=3D PKT_TX_TCP_CKSUM; // *** PKT_TX_TCP_CKSUM is > > marked only if TSO is not applicable *** > > > else { > > > tcp_hdr->cksum =3D > > > get_udptcp_checksum(l3_hdr, tcp_hdr, > > > > > > In other words - testpmd does not set TCP_CKSUM along with TCP_SEG > > > therefore using testpmd with TAP/TSO will result in TCP segments with= 0 > > (incorrect) TCP checksums. > > > > > > In addition - please note the comments in lib/librte_mbuf/rte_mbuf.h > > > which specify that PKT_TX_TCP_SEG flag implies the PKT_TX_TCP_CKSUM > > > (hence it is not required to be explicitly set by the caller) > > > > > > /** > > > * TCP segmentation offload. To enable this offload feature for a > > > * packet to be transmitted on hardware supporting TSO: > > > * - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies > > > * PKT_TX_TCP_CKSUM) > > > ... > > > > > > > Add Konstantin for more suggestions. > > > > > > > > Thanks, > > > > Jiayu > > > > > > > > > -----Original Message----- > > > > > From: Ophir Munk [mailto:ophirmu@mellanox.com] > > > > > Sent: Sunday, April 22, 2018 10:21 PM > > > > > To: dev@dpdk.org; Hu, Jiayu > > > > > Cc: Thomas Monjalon ; Olga Shern > > > > > ; Pascal Mazon ; > > > > Ophir > > > > > Munk ; stable@dpdk.org > > > > > Subject: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > > > segments > > > > > > > > > > Large TCP packets which are marked with PKT_TX_TCP_SEG flag are > > > > > segmented and the flag is cleared in the resulting segments, > > > > > however, the segments checksum is not updated. It is therefore > > > > > required to set the PKT_TX_TCP_CKSUM flag in each TCP segment in > > > > > order to mark for the sending driver the need to update the TCP > > > > > checksum before transmitting the segment. > > > > > > > > > > Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO") > > > > > Cc: stable@dpdk.org > > > > > > > > > > Signed-off-by: Ophir Munk > > > > > --- > > > > > lib/librte_gso/rte_gso.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c > > > > > index a44e3d4..e9ce9ce 100644 > > > > > --- a/lib/librte_gso/rte_gso.c > > > > > +++ b/lib/librte_gso/rte_gso.c > > > > > @@ -50,12 +50,14 @@ rte_gso_segment(struct rte_mbuf *pkt, > > > > > ((IS_IPV4_GRE_TCP4(pkt->ol_flags) && > > > > > (gso_ctx->gso_types & > > > > > DEV_TX_OFFLOAD_GRE_TNL_TSO)))) { > > > > > pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > > > > > + pkt->ol_flags |=3D PKT_TX_TCP_CKSUM; > > > > > ret =3D gso_tunnel_tcp4_segment(pkt, gso_size, ipid_delta, > > > > > direct_pool, indirect_pool, > > > > > pkts_out, nb_pkts_out); > > > > > } else if (IS_IPV4_TCP(pkt->ol_flags) && > > > > > (gso_ctx->gso_types & > > > > > DEV_TX_OFFLOAD_TCP_TSO)) { > > > > > pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > > > > > + pkt->ol_flags |=3D PKT_TX_TCP_CKSUM; > > > > > ret =3D gso_tcp4_segment(pkt, gso_size, ipid_delta, > > > > > direct_pool, indirect_pool, > > > > > pkts_out, nb_pkts_out); > > > > > -- > > > > > 2.7.4