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 4B804A04B5; Wed, 2 Sep 2020 08:26:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 88A4E1C066; Wed, 2 Sep 2020 08:26:46 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 8FB364C99 for ; Wed, 2 Sep 2020 08:26:44 +0200 (CEST) IronPort-SDR: MsP/++RN3MYsrgD0pQtMfQJUyLUWa76aC4RbTvSkSHaxe82GspKbZeWUjR22Oa72b5L5+FswyT A+QvqbK+XSHw== X-IronPort-AV: E=McAfee;i="6000,8403,9731"; a="154731420" X-IronPort-AV: E=Sophos;i="5.76,381,1592895600"; d="scan'208,217";a="154731420" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 23:26:40 -0700 IronPort-SDR: lJJ/kVZ53K4k5Aku0Z8jydo40O6I9ofAtiuHDJI2BfEG7HxihwGkqSlmh4J/eEL8M2ftgwmVaN xosyhqVN6kww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,381,1592895600"; d="scan'208,217";a="325655384" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga004.fm.intel.com with ESMTP; 01 Sep 2020 23:26:40 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by fmsmsx606.amr.corp.intel.com (10.18.126.86) 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 23:26:39 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) 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 14:26:38 +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 14:26:38 +0800 From: "Hu, Jiayu" To: yang_y_yi CC: "dev@dpdk.org" , "thomas@monjalon.net" , "yangyi01@inspur.com" Thread-Topic: Re:RE: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO support Thread-Index: AQHWgDvt5/IHVKlj5Ee5my2a8T/6XqlU1r3Q//9+ogCAAIf/wA== Date: Wed, 2 Sep 2020 06:26:37 +0000 Message-ID: <45a8b506147448588694683e4396e08f@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> <860dbd7705ad47c7ae00c78879e0ac37@intel.com> In-Reply-To: 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" GRO lib requires users to provide correct mbuf->l2_len/packet_type etc.. This is for avoiding parsing packet headers. If we believe users give corre= ct packet_type, we also should believe l2_len/l4_len etc. are correct. Otherwi= se, we need to get layer 4 header length from ipv4 header, rather than mbuf->l4= _len. rte_gro_rx_prepare() is a good way to do sanity check or prepare l2_len etc= . fields, but this function should be optional, IMO. Either user or rte_gro_rx_prepar= e() provides correct l2_len etc. value. Thanks, Jiayu From: yang_y_yi Sent: Wednesday, September 2, 2020 1:58 PM To: Hu, Jiayu Cc: dev@dpdk.org; thomas@monjalon.net; yangyi01@inspur.com Subject: Re:RE: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GR= O support Importance: High Jiayu, TCP header length is variable if there is TCP option, it is usually = 20 if no TCP option, but correct value must be between 20 and 60 (including= 20 and 60), I think we can't assume l4 header length has been set correctl= y if packet_type is set correctly, this is my point. I think it will be bet= ter if we can add a rte_gro_rx_prepare as rte_eth_tx_prepare. GRO can't wor= k normally only if one of all the related fields isn't set correctly. So I = don't think such sanity check is a bad thing. At 2020-09-02 13:44:56, "Hu, Jiayu" > wrote: 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; >