From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8D5D0A04B5; Wed, 2 Sep 2020 07:45:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 838301C069; Wed, 2 Sep 2020 07:45:05 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 545431C066 for ; Wed, 2 Sep 2020 07:45:03 +0200 (CEST) IronPort-SDR: iRPloIhdi0Km5GF6spfZSyZXZujkEChfAwYwz1VKY0fZd+dw6Cs2jZuR2eXXUMU/FCNgG2AcZq 6o2/Rico9VLQ== X-IronPort-AV: E=McAfee;i="6000,8403,9731"; a="175373730" X-IronPort-AV: E=Sophos;i="5.76,381,1592895600"; d="scan'208,217";a="175373730" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 22:45:00 -0700 IronPort-SDR: 8MNBxhd7hXvUgJoMFg1cfcMCk2EwyGBnGFF5ure2Wy2v1rqeVBb+wF0/RzmOBkReKaqFac+bYr DydPk8/R5R0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,381,1592895600"; d="scan'208,217";a="325645164" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga004.fm.intel.com with ESMTP; 01 Sep 2020 22:44:59 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 1 Sep 2020 22:44:58 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by SHSMSX606.ccr.corp.intel.com (10.109.6.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 2 Sep 2020 13:44:56 +0800 Received: from shsmsx606.ccr.corp.intel.com ([10.109.6.216]) by SHSMSX606.ccr.corp.intel.com ([10.109.6.216]) with mapi id 15.01.1713.004; Wed, 2 Sep 2020 13:44:56 +0800 From: "Hu, Jiayu" To: yang_y_yi CC: "dev@dpdk.org" , "thomas@monjalon.net" , "yangyi01@inspur.com" Thread-Topic: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO support Thread-Index: AQHWgDvt5/IHVKlj5Ee5my2a8T/6XqlU1r3Q Date: Wed, 2 Sep 2020 05:44:56 +0000 Message-ID: <860dbd7705ad47c7ae00c78879e0ac37@intel.com> References: <20200701064800.222400-1-yang_y_yi@163.com> <7b56d9d7.4058.1744849f8c6.Coremail.yang_y_yi@163.com> <40ffd2af.60ca.17448d52847.Coremail.yang_y_yi@163.com> In-Reply-To: <40ffd2af.60ca.17448d52847.Coremail.yang_y_yi@163.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Yi, Packet type is checked by mbuf->packet_type field, and input packets should provide correct packet_type value. TCP GRO only process TCP packets whose header length is between 20 and 60 bytes. So we check l4_len. From: yang_y_yi Sent: Tuesday, September 1, 2020 4:43 PM To: Hu, Jiayu Cc: dev@dpdk.org; thomas@monjalon.net; yangyi01@inspur.com Subject: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO suppo= rt Jiayu, BTW, after I check it again, I think udp header length check is nece= ssary, it is actually a sanity check io order to ensure it is indeed a udp = packet, gro_tcp4.c did same thing. At 2020-09-01 14:10:41, "yang_y_yi" > wrote: >At 2020-09-01 12:27:29, "Hu, Jiayu" > wrote: >>Hi Yi, >> >>This patch supports UDP and VxLAN/UDP, but both are in one patch. >>It's too large, and please split it into small patches. > >Jiayu, thank you so much for your great review , I'll send v2 to split it = into two patches and fix your comments. Detailed replies for comments embed= ded, please check them. > >> >>Thanks, >>Jiayu >> >>> -----Original Message----- >>> From: yang_y_yi@163.com > >>> Sent: Wednesday, July 1, 2020 2:48 PM >>> To: dev@dpdk.org >>> Cc: Hu, Jiayu >; thomas@m= onjalon.net; >>> yangyi01@inspur.com; yang_y_yi@163.com >>> Subject: [PATCH] gro: add UDP GRO and VXLAN UDP GRO support >>> >>> From: Yi Yang > >>> >>> UDP GRO and VXLAN UDP GRO can help improve VM-to-VM >>> UDP performance when VM is enabled UFO or GSO, GRO >>> must be supported if GSO, UFO or VXLAN UFO is enabled >>> , otherwise, performance gain will be hurt. >>> >>> With this enabled in DPDK, OVS DPDK can leverage it >>> to improve VM-to-VM UDP performance, this will make >>> sure IP fragments will be reassembled once it is >>> received from physical NIC. >>> >>> Signed-off-by: Yi Yang = > >>> --- >>> lib/librte_gro/Makefile | 2 + >>> lib/librte_gro/gro_udp4.c | 443 ++++++++++++++++++++++++++++++++ >>> lib/librte_gro/gro_udp4.h | 296 +++++++++++++++++++++ >>> lib/librte_gro/gro_vxlan_udp4.c | 556 >>> ++++++++++++++++++++++++++++++++++++++++ >>> lib/librte_gro/gro_vxlan_udp4.h | 152 +++++++++++ >>> lib/librte_gro/meson.build | 2 +- >>> lib/librte_gro/rte_gro.c | 192 +++++++++++--- >>> lib/librte_gro/rte_gro.h | 8 +- >>> 8 files changed, 1617 insertions(+), 34 deletions(-) >>> create mode 100644 lib/librte_gro/gro_udp4.c >>> create mode 100644 lib/librte_gro/gro_udp4.h >>> create mode 100644 lib/librte_gro/gro_vxlan_udp4.c >>> create mode 100644 lib/librte_gro/gro_vxlan_udp4.h >>> + >>> + >>> +/* >>> + * update the packet length for the flushed packet. >>> + */ >>> +static inline void >>> +update_header(struct gro_udp4_item *item) >>> +{ >>> + struct rte_ipv4_hdr *ipv4_hdr; >>> + struct rte_mbuf *pkt =3D item->firstseg; >>> + uint16_t frag_offset; >>> + >>> + ipv4_hdr =3D (struct rte_ipv4_hdr *)(rte_pktmbuf_mtod(pkt, char *) + >>> + pkt->l2_len); >>> + ipv4_hdr->total_length =3D rte_cpu_to_be_16(pkt->pkt_len - >>> + pkt->l2_len); >>> + >>> + /* Clear MF bit if it is last fragment */ >>> + if (item->is_last_frag) { >>> + frag_offset =3D rte_be_to_cpu_16(ipv4_hdr->fragment_offset); >>> + ipv4_hdr->fragment_offset =3D >>> + rte_cpu_to_be_16(frag_offset & >>> ~RTE_IPV4_HDR_MF_FLAG); >>> + } >> >>Need to clear MF bit for non-last fragments, and we also need to clear of= fset value. > >For non-last fragment, MF (More Fragment) bit is necessary, why do you thi= nk we need to clear MF bit for it? Only last fragment should clear MF bit. = offset value must be set correctly because it is a IP fragment. > >> >>> +} >>> + >>> +int32_t >>> +gro_udp4_reassemble(struct rte_mbuf *pkt, >>> + struct gro_udp4_tbl *tbl, >>> + uint64_t start_time) >>> +{ >>> + struct rte_ether_hdr *eth_hdr; >>> + struct rte_ipv4_hdr *ipv4_hdr; >>> + uint16_t udp_dl, ip_dl; >>> + uint16_t ip_id, hdr_len; >>> + uint16_t frag_offset =3D 0; >>> + uint8_t is_last_frag; >>> + >>> + struct udp4_flow_key key; >>> + uint32_t cur_idx, prev_idx, item_idx; >>> + uint32_t i, max_flow_num, remaining_flow_num; >>> + int cmp; >>> + uint8_t find; >>> + >>> + /* >>> + * Don't process the packet whose UDP header length is not equal >>> + * to 20. >>> + */ >>> + if (unlikely(pkt->l4_len !=3D UDP_HDRLEN)) >>> + return -1; >> >>UDP header is fixed 8-byte. No need to check here. > >Agree, will remove it in v2. > >> >>> + >>> + eth_hdr =3D rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *); >>> + ipv4_hdr =3D (struct rte_ipv4_hdr *)((char *)eth_hdr + pkt->l2_len); >>> + hdr_len =3D pkt->l2_len + pkt->l3_len + pkt->l4_len; >>> + >>> + /* >>> + * Don't process non-fragment packet. >>> + */ >>> + if (!is_ipv4_fragment(ipv4_hdr)) >>> + return -1; >>> + >>> + /* >>> + * Don't process the packet whose payload length is less than or >>> + * equal to 0. >>> + */ >>> + udp_dl =3D pkt->pkt_len - hdr_len; >>> + if (udp_dl <=3D 0) >>> + return -1; >> >>Udp_dl is unit16_t which will not be negative. > >Good catch, I should use int16_t here, will do it in v2. > >> >>> + >>> + ip_dl =3D rte_be_to_cpu_16(ipv4_hdr->total_length) - pkt->l3_len; >>> + ip_id =3D rte_be_to_cpu_16(ipv4_hdr->packet_id); >>> + frag_offset =3D rte_be_to_cpu_16(ipv4_hdr->fragment_offset); >>> + is_last_frag =3D ((frag_offset & RTE_IPV4_HDR_MF_FLAG) =3D=3D 0) ? 1= : 0; >>> + frag_offset =3D (uint16_t)(frag_offset & RTE_IPV4_HDR_OFFSET_MASK) >>> << 3; >