From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 629391B669 for ; Wed, 4 Oct 2017 16:49:10 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2017 07:49:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,477,1500966000"; d="scan'208";a="156646386" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga005.jf.intel.com with ESMTP; 04 Oct 2017 07:49:08 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 4 Oct 2017 15:49:07 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.49]) by irsmsx112.ger.corp.intel.com ([169.254.1.142]) with mapi id 14.03.0319.002; Wed, 4 Oct 2017 15:49:07 +0100 From: "Ananyev, Konstantin" To: "Kavanagh, Mark B" , "dev@dpdk.org" CC: "Hu, Jiayu" , "Tan, Jianfeng" , "Yigit, Ferruh" , "thomas@monjalon.net" Thread-Topic: [PATCH v6 2/6] gso: add TCP/IPv4 GSO support Thread-Index: AQHTO5328sRz3LI55k+Gpuim5UFNzaLTsgnwgAAAugCAABSXQA== Date: Wed, 4 Oct 2017 14:49:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772585FAA3E3A@IRSMSX103.ger.corp.intel.com> References: <1506636833-25851-1-git-send-email-mark.b.kavanagh@intel.com> <1506962749-106779-1-git-send-email-mark.b.kavanagh@intel.com> <1506962749-106779-3-git-send-email-mark.b.kavanagh@intel.com> <2601191342CEEE43887BDE71AB9772585FAA3D5A@IRSMSX103.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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDE5NGE4MTktMTUxZC00NWFjLWFiMjktZDdjNGQ5NTgzYWIwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImNOMkxlUkFvXC9TXC83MGJYcmNLb0VSbVJWQURQcml4NHNhN1MzVUllUHlNaz0ifQ== x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 2/6] gso: add TCP/IPv4 GSO 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: Wed, 04 Oct 2017 14:49:11 -0000 > >> int > >> rte_gso_segment(struct rte_mbuf *pkt, > >> @@ -41,12 +46,53 @@ > >> struct rte_mbuf **pkts_out, > >> uint16_t nb_pkts_out) > >> { > >> + struct rte_mempool *direct_pool, *indirect_pool; > >> + struct rte_mbuf *pkt_seg; > >> + uint64_t ol_flags; > >> + uint16_t gso_size; > >> + uint8_t ipid_delta; > >> + int ret =3D 1; > >> + > >> if (pkt =3D=3D NULL || pkts_out =3D=3D NULL || gso_ctx =3D=3D NULL |= | > >> nb_pkts_out < 1) > >> return -EINVAL; > >> > >> - pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > >> - pkts_out[0] =3D pkt; > >> + if ((gso_ctx->gso_size >=3D pkt->pkt_len) || (gso_ctx->gso_types & > >> + DEV_TX_OFFLOAD_TCP_TSO) !=3D > >> + gso_ctx->gso_types) { > >> + pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > >> + pkts_out[0] =3D pkt; > >> + return 1; > >> + } > >> + > >> + direct_pool =3D gso_ctx->direct_pool; > >> + indirect_pool =3D gso_ctx->indirect_pool; > >> + gso_size =3D gso_ctx->gso_size; > >> + ipid_delta =3D (gso_ctx->ipid_flag !=3D RTE_GSO_IPID_FIXED); > >> + ol_flags =3D pkt->ol_flags; > >> + > >> + if (IS_IPV4_TCP(pkt->ol_flags)) { > >> + pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > >> + ret =3D gso_tcp4_segment(pkt, gso_size, ipid_delta, > >> + direct_pool, indirect_pool, > >> + pkts_out, nb_pkts_out); > >> + } else { > >> + pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > > > >Not sure why do you clean this flag if you don't support that packet typ= e > >and no action was perfomed? > >Suppose you have a mix ipv4 and ipv6 packets - gso lib would do ipv4 and > >someone else > >(HW?) can do ipv4 segmentation. >=20 > I can't say for definite, since I didn't implement this change. However, = I can only presume that the assumption here is that since > segmentation is being done in S/W that the underlying H/W does not suppor= t TSO. > Since the underlying HW can't segment the packet in HW, we should clear t= he flag; otherwise, if an mbuf marked for TCP segmentation is > passed to the driver of a NIC that does not support/understand that featu= re, the behavior is undefined. > Is this a fair assumption in your opinion, or is it the case that the pac= ket would simply be transmitted un-segmented in that case, and so we > shouldn't clear the flag? Yes, I think if we shouldn't clear the flag if we didn't do any segmentatio= n (we just encounter a packet type that we don't support). Konstantin >=20 > Thanks again, > Mark >=20 > >BTW, did you notice that building of shared target fails? > >Konstantin >=20 > I didn't, but I'll take a look right now - thanks for the catch! >=20 > > > > > >> + pkts_out[0] =3D pkt; > >> + RTE_LOG(WARNING, GSO, "Unsupported packet type\n"); > >> + return 1; > >> + } > >> + > >> + if (ret > 1) { > >> + pkt_seg =3D pkt; > >> + while (pkt_seg) { > >> + rte_mbuf_refcnt_update(pkt_seg, -1); > >> + pkt_seg =3D pkt_seg->next; > >> + } > >> + } else if (ret < 0) { > >> + /* Revert the ol_flags in the event of failure. */ > >> + pkt->ol_flags =3D ol_flags; > >> + } > >> > >> - return 1; > >> + return ret; > >> } > >> -- > >> 1.9.3