From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 9C9892C17 for ; Tue, 5 Sep 2017 03:09:04 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 18:09:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,477,1498546800"; d="scan'208";a="147446267" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 04 Sep 2017 18:09:03 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 4 Sep 2017 18:09:03 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 4 Sep 2017 18:09:03 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.39]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.93]) with mapi id 14.03.0319.002; Tue, 5 Sep 2017 09:09:02 +0800 From: "Hu, Jiayu" To: "Ananyev, Konstantin" CC: "dev@dpdk.org" , "Kavanagh, Mark B" , "Tan, Jianfeng" Thread-Topic: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support Thread-Index: AQHTJWPYDDaZn+Uekkm4mMHxlpdSrKKleI8Q Date: Tue, 5 Sep 2017 01:09:01 +0000 Message-ID: References: <1503584144-63181-1-git-send-email-jiayu.hu@intel.com> <1503584144-63181-3-git-send-email-jiayu.hu@intel.com> <2601191342CEEE43887BDE71AB9772584F23E097@IRSMSX103.ger.corp.intel.com> <20170904033150.GA9009@dpdk15.sh.intel.com> <2601191342CEEE43887BDE71AB9772584F244E8C@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F244E8C@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWM4MzkxOTQtOGMxNy00ZTkxLTg4NjktMDVlMDA3ZTMyODhkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImpUaG5ORDRqVlwvZDM0eHR1cCtiWTIyREpvdm1kU2F2d0xEZXFVVnNuVUZrPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/5] gso/lib: 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: Tue, 05 Sep 2017 01:09:06 -0000 Hi Konstantin, > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, September 4, 2017 5:55 PM > To: Hu, Jiayu > Cc: dev@dpdk.org; Kavanagh, Mark B ; Tan, > Jianfeng > Subject: RE: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support >=20 > Hi Jiayu, >=20 > > -----Original Message----- > > From: Hu, Jiayu > > Sent: Monday, September 4, 2017 4:32 AM > > To: Ananyev, Konstantin > > Cc: dev@dpdk.org; Kavanagh, Mark B ; Tan, > Jianfeng > > Subject: Re: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support > > > > Hi Konstantin, > > > > About the IP identifier, I check the linux codes and have some feedback= s > inline. > > > > On Wed, Aug 30, 2017 at 09:38:33AM +0800, Ananyev, Konstantin wrote: > > > > > > > > > > -----Original Message----- > > > > From: Hu, Jiayu > > > > Sent: Thursday, August 24, 2017 3:16 PM > > > > To: dev@dpdk.org > > > > Cc: Kavanagh, Mark B ; Ananyev, > Konstantin ; Tan, Jianfeng > > > > ; Hu, Jiayu > > > > Subject: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support > > > > > > > > This patch adds GSO support for TCP/IPv4 packets. Supported packets > > > > may include a single VLAN tag. TCP/IPv4 GSO assumes that all input > > > > packets have correct checksums, and doesn't update checksums for > output > > > > packets (the responsibility for this lies with the application). > > > > Additionally, TCP/IPv4 GSO doesn't process IP fragmented packets. > > > > > > > > TCP/IPv4 GSO uses two chained MBUFs, one direct MBUF and one > indrect > > > > MBUF, to organize an output packet. Note that we refer to these two > > > > chained MBUFs as a two-segment MBUF. The direct MBUF stores the > packet > > > > header, while the indirect mbuf simply points to a location within = the > > > > original packet's payload. Consequently, use of the GSO library req= uires > > > > multi-segment MBUF support in the TX functions of the NIC driver. > > > > > > > > If a packet is GSOed, TCP/IPv4 GSO reduces its MBUF refcnt by 1. As= a > > > > result, when all of its GSOed segments are freed, the packet is fre= ed > > > > automatically. > > > > > > > > Signed-off-by: Jiayu Hu > > > > Signed-off-by: Mark Kavanagh > > > > --- > > > > +void > > > > +gso_update_pkt_headers(struct rte_mbuf *pkt, uint16_t nb_segments, > > > > + struct rte_mbuf **out_segments) > > > > +{ > > > > + struct ipv4_hdr *ipv4_hdr; > > > > + struct tcp_hdr *tcp_hdr; > > > > + struct rte_mbuf *seg; > > > > + uint32_t sent_seq; > > > > + uint16_t offset, i; > > > > + uint16_t tail_seg_idx =3D nb_segments - 1, id; > > > > + > > > > + switch (pkt->packet_type) { > > > > + case ETHER_VLAN_IPv4_TCP_PKT: > > > > + case ETHER_IPv4_TCP_PKT: > > > > > > Might be worth to put code below in a separate function: > > > update_inner_tcp_hdr(..) or so. > > > Then you can reuse it for tunneled cases too. > > > > > > > + ipv4_hdr =3D (struct ipv4_hdr *)(rte_pktmbuf_mtod(pkt, char *) > > > > + pkt->l2_len); > > > > + tcp_hdr =3D (struct tcp_hdr *)((char *)ipv4_hdr + pkt->l3_len); > > > > + id =3D rte_be_to_cpu_16(ipv4_hdr->packet_id); > > > > + sent_seq =3D rte_be_to_cpu_32(tcp_hdr->sent_seq); > > > > + > > > > + for (i =3D 0; i < nb_segments; i++) { > > > > + seg =3D out_segments[i]; > > > > + > > > > + offset =3D seg->l2_len; > > > > + update_ipv4_header(rte_pktmbuf_mtod(seg, char *), > > > > + offset, seg->pkt_len, id); > > > > + id++; > > > > > > Who would be responsible to make sure that we wouldn't have > consecutive packets with the IPV4 id? > > > Would be the upper layer that forms the packet or gso library or ...? > > > > Linux supports two kinds of IP identifier: fixed identifier and increme= ntal > identifier, and > > which one to use depends on upper protocol modules. Specifically, if th= e > protocol module > > wants fixed identifiers, it will set SKB_GSO_TCP_FIXEDID to skb->gso_ty= pe, > and then > > inet_gso_segment() will keep identifiers the same. Otherwise, all segme= nts > will have > > incremental identifiers. The reason for this design is that some protoc= ols > may choose fixed > > IP identifiers, like TCP (from RFC791). This design also shows that lin= ux > ignores the issue > > of repeated IP identifiers. > > > > From the perspective of DPDK, we need to solve two problems. One is if > ignore the issue of > > repeated IP identifiers. The other is if the GSO library provides an in= terface > to upper > > applications to enable them to choose fixed or incremental identifiers,= or > simply uses > > incremental IP identifiers. > > > > Do you have any suggestions? >=20 >=20 > Do the same as Linux? > I.E. add some flag RRE_GSO_IPID_FIXED (or so) into gso_ctx? OK, I see. We can do that. In the GRO library, we check if the IP identifiers are incremental compulso= rily. If we enable fixed IP identifier in GSO, it seems we also need to change the GRO = library. I mean ignore IP identifier when merge packets, and don't update the IP ide= ntifier for the merged packet. What do you think of it? Thanks, Jiayu > Konstantin >=20 > > > > Thanks, > > Jiayu > > > > > > > > > + > > > > + offset +=3D seg->l3_len; > > > > + update_tcp_header(rte_pktmbuf_mtod(seg, char *), > > > > + offset, sent_seq, i < tail_seg_idx); > > > > + sent_seq +=3D seg->next->data_len; > > > > + } > > > > + break; > > > > + } > > > > +} > > > > -- > > > > 2.7.4