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 5F2DEA04B5; Mon, 26 Oct 2020 02:56:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A5B9D1E2B; Mon, 26 Oct 2020 02:56:48 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BFC571D9E; Mon, 26 Oct 2020 02:56:45 +0100 (CET) IronPort-SDR: PeMs8pLITlZNx34EZWPMgM/hmD8AJVt+j8yXUdeaK8+t+hE4v8COrOG0klyjJ2Q6Qyt9kJQ5P5 vTneawrFQaiw== X-IronPort-AV: E=McAfee;i="6000,8403,9785"; a="167964870" X-IronPort-AV: E=Sophos;i="5.77,417,1596524400"; d="scan'208";a="167964870" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2020 18:56:43 -0700 IronPort-SDR: UjX0794Ns/WqJJclh7hFRd0Rfr/yqep481vBJPeT/Nrrh207WOn+smqhYlsq1CZfFgjP6iiGd/ ULZINn052Sow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,417,1596524400"; d="scan'208";a="349945470" Received: from npg_dpdk_virtio_jiayuhu_15.sh.intel.com ([10.67.117.43]) by fmsmga004.fm.intel.com with ESMTP; 25 Oct 2020 18:56:41 -0700 Date: Mon, 26 Oct 2020 10:06:09 +0800 From: Jiayu Hu To: yang_y_yi ;, konstantin.ananyev@intel.com Cc: dev@dpdk.org;, techboard@dpdk.org;, thomas@monjalon.net;, yangyi01@inspur.com Message-ID: <20201026020609.GA82482@NPG_DPDK_VIRTIO_jiayuhu_15.sh.intel.com> References: <20201022065151.10108-1-yang_y_yi@163.com> <3dcc6d13.74bb.175559c0cf4.Coremail.yang_y_yi@163.com> <40321786.799.175626903ce.Coremail.yang_y_yi@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40321786.799.175626903ce.Coremail.yang_y_yi@163.com> User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH v2] gso: fix free issue of mbuf gso segments attach to 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" On Mon, Oct 26, 2020 at 08:57:30AM +0800, yang_y_yi wrote: > At 2020-10-23 22:46:42, "Ananyev, Konstantin" > wrote: > > >> From: yang_y_yi > >> Sent: Friday, October 23, 2020 2:18 PM > >> To: Ananyev, Konstantin > >> Cc: dev@dpdk.org; Hu, Jiayu ; techboard@dpdk.org; thomas@monjalon.net; yangyi01@inspur.com > >> Subject: Re:RE: [PATCH v2] gso: fix free issue of mbuf gso segments attach to > >> > >> Konstantin, thank you so much for comments, my replies inline, please check them. > >> At 2020-10-22 21:16:43, "Ananyev, Konstantin" wrote: > >> > > >> >> > >> >> rte_gso_segment decreased refcnt of pkt by one, but > >> >> it is wrong if pkt is external mbuf, pkt won't be > >> >> freed because of incorrect refcnt, the result is > >> >> application can't allocate mbuf from mempool because > >> >> mbufs in mempool are run out of. > >> >> > >> >> One correct way is application should call > >> >> rte_pktmbuf_free after calling rte_gso_segment to free > >> >> pkt explicitly. rte_gso_segment mustn't handle it, this > >> >> should be responsibility of application. > >> > > >> >Probably needs to be stated clearly: > >> >It is a change in functional behaviour. > >> >Without deprecation note in advance. > >> > >> Ok, I'll add such statement in next version. > >> > >> >TB members: please provide your opinion on that patch. > >> > > >> >> > >> >> Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO") > >> >> Signed-off-by: Yi Yang > >> >> --- > >> >> Changelog: > >> >> > >> >> v1->v2: > >> >> - update description of rte_gso_segment(). > >> >> - change code which calls rte_gso_segment() to > >> >> fix free issue. > >> >> > >> >> --- > >> >> app/test-pmd/csumonly.c | 3 ++- > >> >> doc/guides/prog_guide/generic_segmentation_offload_lib.rst | 7 +++++-- > >> > > >> >I think release notes also have to be updated. > >> > >> Ok, also will update it to reflect this change. > >> > >> > > >> >> lib/librte_gso/rte_gso.c | 9 +-------- > >> >> lib/librte_gso/rte_gso.h | 7 +++++-- > >> >> 4 files changed, 13 insertions(+), 13 deletions(-) > >> >> > >> >> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c > >> >> index 3d7d244..829e07f 100644 > >> >> --- a/app/test-pmd/csumonly.c > >> >> +++ b/app/test-pmd/csumonly.c > >> >> @@ -1080,11 +1080,12 @@ struct simple_gre_hdr { > >> >> ret = rte_gso_segment(pkts_burst[i], gso_ctx, > >> >> &gso_segments[nb_segments], > >> >> GSO_MAX_PKT_BURST - nb_segments); > >> >> + /* pkts_burst[i] can be freed safely here. */ > >> >> + rte_pktmbuf_free(pkts_burst[i]); > >> > > >> >It doesn't look correct to me. > >> >I think it should be: > >> >If (ret > 1) rte_pktmbuf_free(pkts_burst[i]); > >> > >> No, in original implementation, if gso failed, application will free it, otherwise rte_gso_segment will free it (i.e. refcnt update -1 in > >> rte_gso_segment), this change will change previous behavior. application will free it for both cases. > > > > > >That's the point - with current implementation: > >If ret == 1, then you shouldn't free input packet. > >Because in that case: > >input_pkt == output_pkt[0] > > > >And if you'll free it, you can't use it after it. > >In that particular case, you can't TX it. > > I checked gso code again, there are two cases even if ret == 1, one case is it isn't segmented, the other is it is segmented but gso_do_segment returns 1, for case #1, we can handle it as you said, but for case #2, we can't handle it as you said because it has been segmented in fact. So I think we should return 0 foe case #1 and don't do assignment "pkts_out[0] = pkt;", we should handle case #2 as before, right? > When will #2 case happen? In current implementation, ret of gso_do_segment() is > 1, when GSO happens; otherwise, ret is negative. It doesn't return 1. If you mean the case that pkt_len is smaller than gso_size, gso_do_segment() will not be called, since rte_gso_segment() will compare pkt_len and gso_size before. Thanks, Jiayu > > > >> > > > > >