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 6DFDEA04DF for ; Fri, 30 Oct 2020 10:31:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4D8349AFD; Fri, 30 Oct 2020 10:31:56 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id 2EB519AFD for ; Fri, 30 Oct 2020 10:31:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604050313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fh1TXQYQu7z0yaLsYAhEOMggCJR1hnMxR6fk3G9t2Nw=; b=QR+SrX8It+F54AMn5Zc92jICTC1uDWjiNMgclaXUFwpk2HCJzLnQ4uaXt/QzW/v3l4Yi+T ZXDJ5/q8fD4ls+ybB5iwhjX78sbBvo/yedqoIZb7JwMq1GP/53lBHr+By8+7DxVbt7k5mU 1A/kQvasX7HELPf8Ph17Na6BzicbVQA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-JOz3edMHPHqz27jqF0ws0Q-1; Fri, 30 Oct 2020 05:31:49 -0400 X-MC-Unique: JOz3edMHPHqz27jqF0ws0Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D0E7110A0BB2; Fri, 30 Oct 2020 09:31:17 +0000 (UTC) Received: from [10.36.114.240] (ovpn-114-240.ams2.redhat.com [10.36.114.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id AEEC8100239A; Fri, 30 Oct 2020 09:31:15 +0000 (UTC) To: =?UTF-8?B?WWkgWWFuZyAo5p2o54eaKS3kupHmnI3liqHpm4blm6I=?= , "bluca@debian.org" Cc: "jiayu.hu@intel.com" , "stable@dpdk.org" , "ian.stokes@intel.com" , "i.maximets@ovn.org" References: <80d133df2f898e981b70b13c36ac63c3@sslemail.net> <20201028104606.3504127-46-luca.boccassi@gmail.com> <9cb44a156b104230994d36e08b2285a3@inspur.com> <76c922d09091b43e4a2fe36be9ac1e2e4b664f96.camel@debian.org> From: Kevin Traynor Message-ID: <419d656b-1fbf-34a9-9f54-6ad653cda4ee@redhat.com> Date: Fri, 30 Oct 2020 09:31:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] =?utf-8?b?562U5aSNOiAg562U5aSNOiBwYXRjaCAnZ3NvOiBm?= =?utf-8?q?ix_payload_unit_size_for_UDP=27_has_been_queued_to_stable_relea?= =?utf-8?q?se_19=2E11=2E6?= 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: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 30/10/2020 00:26, Yi Yang (杨燚)-云服务集团 wrote: > Got it, thanks Kevin for comments. How can I use 'dpdk-latest' for OVS DPDK build in travis and local machine? Any existing guide for using 'dpdk-latest'? > You can use it the same way you use OVS master branch, except pairing with DPDK main branch instead of 19.11. Patches for it should have [PATCH dpdk-latest]. I'm not sure if the robot runs travis for patches on it, I don't think so - I guess you can run it with your own travis account. > -----邮件原件----- > 发件人: Kevin Traynor [mailto:ktraynor@redhat.com] > 发送时间: 2020年10月29日 19:29 > 收件人: Luca Boccassi ; Yi Yang (杨燚)-云服务集团 > 抄送: jiayu.hu@intel.com; stable@dpdk.org; Ian Stokes ; Ilya Maximets > 主题: Re: [dpdk-stable] 答复: patch 'gso: fix payload unit size for UDP' has been queued to stable release 19.11.6 > > On 29/10/2020 11:10, Luca Boccassi wrote: >> Hi, >> >> Sorry, but it seems to me adding entire new features in the shared >> libraries is a bit over the grey line that separates what we deem an >> acceptable change for a stable release. >> >> On Thu, 2020-10-29 at 04:45 +0000, Yi Yang (杨燚)-云服务集团 wrote: >>> Thanks for picking up it, nice to have it in stable release. By the way, would you like to cherry-pick GRO patches for stable release? OVS is using 19.11 stable branch, we had better have GRO support there because I'm enabling VXLAN TSO support in OVS DPDK, GRO and GSO are necessary for it. >>> > > OVS normally uses the the latest DPDK LTS, so it should be moving to > 20.11 in the next couple of months. There is an OVS branch called 'dpdk-latest' for developing against the DPDK main branch, so you should be able to test and send patches for it in preparation of OVS using 20.11. > >>> commit e2d81106367321cf49d6b4e5d087e1a7c2e808ba >>> Author: Yi Yang >>> Date: Thu Sep 24 16:57:39 2020 +0800 >>> >>> gro: support VXLAN UDP/IPv4 >>> >>> VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP >>> performance when UFO or GSO is enabled in VM, GRO >>> must be supported if UFO or GSO is enabled, >>> otherwise, performance can't get big improvement >>> if only GSO is there. >>> >>> With this enabled in DPDK, OVS DPDK can leverage it >>> to improve VM-to-VM UDP performance, it will reassemble >>> VXLAN UDP/IPv4 fragments immediate after they are >>> received from a physical NIC. It is very helpful in >>> OVS DPDK VXLAN use case. >>> >>> Signed-off-by: Yi Yang >>> Acked-by: Jiayu Hu >>> >>> >>> commit 1ca5e67408528b9870bb40f400c5f934aa91dcce >>> Author: Yi Yang >>> Date: Thu Sep 24 16:57:38 2020 +0800 >>> >>> gro: support UDP/IPv4 >>> >>> UDP/IPv4 GRO can help improve VM-to-VM UDP performance >>> when UFO or GSO is enabled in VM, GRO must be supported >>> if UFO or GSO is enabled, otherwise, performance can't >>> get big improvement if only GSO is there. >>> >>> With this enabled in DPDK, OVS DPDK can leverage it >>> to improve VM-to-VM UDP performance, it will reassemble >>> UDP fragments immediate after they are received from >>> a physical NIC. It is very helpful in OVS DPDK VLAN use >>> case. >>> >>> Signed-off-by: Yi Yang >>> Acked-by: Jiayu Hu >>> >>> -----邮件原件----- >>> 发件人: luca.boccassi@gmail.com [mailto:luca.boccassi@gmail.com] >>> 发送时间: 2020年10月28日 18:43 >>> 收件人: Yi Yang (杨燚)-云服务集团 >>> 抄送: Jiayu Hu ; dpdk stable >>> 主题: patch 'gso: fix payload unit size for UDP' has been queued to >>> stable release 19.11.6 >>> >>> Hi, >>> >>> FYI, your patch has been queued to stable release 19.11.6 >>> >>> Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. >>> It will be pushed if I get no objections before 10/30/20. So please shout if anyone has objections. >>> >>> Also note that after the patch there's a diff of the upstream commit >>> vs the patch applied to the branch. This will indicate if there was >>> any rebasing needed to apply to the stable branch. If there were code >>> changes for rebasing >>> (ie: not only metadata diffs), please double check that the rebase was correctly done. >>> >>> Thanks. >>> >>> Luca Boccassi >>> >>> --- >>> From 2b26f143b3014d23a31aa59deda659b172edcc32 Mon Sep 17 00:00:00 >>> 2001 >>> From: Yi Yang >>> Date: Thu, 17 Sep 2020 10:12:49 +0800 >>> Subject: [PATCH] gso: fix payload unit size for UDP >>> >>> [ upstream commit b9b75d9b5c9dbc71ee12f77e9abe089492708aae ] >>> >>> Fragment offset of IPv4 header is measured in units of >>> 8 bytes. Fragment offset of UDP fragments will be wrong after GSO if pyld_unit_size isn't multiple of 8. Say pyld_unit_size is 1500, fragment offset of the second UDP fragment will be 187 (i.e. 1500 / 8), which means 1496, and it will result in 4-byte data loss (1500 - 1496 = 4). >>> So UDP GRO will reassemble out a wrong packet. >>> >>> Fixes: b166d4f30b66 ("gso: support UDP/IPv4 fragmentation") >>> >>> Signed-off-by: Yi Yang >>> Acked-by: Jiayu Hu >>> --- >>> lib/librte_gso/gso_udp4.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/lib/librte_gso/gso_udp4.c b/lib/librte_gso/gso_udp4.c >>> index 21fea09273..6fa68f243a 100644 >>> --- a/lib/librte_gso/gso_udp4.c >>> +++ b/lib/librte_gso/gso_udp4.c >>> @@ -69,7 +69,10 @@ gso_udp4_segment(struct rte_mbuf *pkt, >>> return 1; >>> } >>> >>> - pyld_unit_size = gso_size - hdr_offset; >>> + /* pyld_unit_size must be a multiple of 8 because frag_off >>> + * uses 8 bytes as unit. >>> + */ >>> + pyld_unit_size = (gso_size - hdr_offset) & ~7U; >>> >>> /* Segment the payload */ >>> ret = gso_do_segment(pkt, hdr_offset, pyld_unit_size, direct_pool, >>> -- >>> 2.20.1 >>> >>> --- >>> Diff of the applied patch vs upstream commit (please double-check if non-empty: >>> --- >>> --- - 2020-10-28 10:35:13.228089104 +0000 >>> +++ 0046-gso-fix-payload-unit-size-for-UDP.patch 2020-10-28 10:35:11.508830082 +0000 >>> @@ -1,8 +1,10 @@ >>> -From b9b75d9b5c9dbc71ee12f77e9abe089492708aae Mon Sep 17 00:00:00 >>> 2001 >>> +From 2b26f143b3014d23a31aa59deda659b172edcc32 Mon Sep 17 00:00:00 >>> +2001 >>> From: Yi Yang >>> Date: Thu, 17 Sep 2020 10:12:49 +0800 >>> Subject: [PATCH] gso: fix payload unit size for UDP >>> >>> +[ upstream commit b9b75d9b5c9dbc71ee12f77e9abe089492708aae ] >>> + >>> Fragment offset of IPv4 header is measured in units of >>> 8 bytes. Fragment offset of UDP fragments will be wrong after GSO if pyld_unit_size isn't multiple of 8. Say @@ -12,7 +14,6 @@ So UDP GRO will reassemble out a wrong packet. >>> >>> Fixes: b166d4f30b66 ("gso: support UDP/IPv4 fragmentation") >>> -Cc: stable@dpdk.org >>> >>> Signed-off-by: Yi Yang >>> Acked-by: Jiayu Hu >> >