On Mon, Oct 26, 2020 at 10:12:24AM +0800, yang_y_yi wrote: > At 2020-10-26 10:06:09, "Jiayu Hu" <jiayu...@intel.com> wrote: > > >On Mon, Oct 26, 2020 at 08:57:30AM +0800, yang_y_yi wrote: > >> At 2020-10-23 22:46:42, "Ananyev, Konstantin" > >> <konstantin.anan...@intel.com> > >> wrote: > >> > >> >> From: yang_y_yi <yang_y...@163.com> > >> >> Sent: Friday, October 23, 2020 2:18 PM > >> >> To: Ananyev, Konstantin <konstantin.anan...@intel.com> > >> >> Cc: dev@dpdk.org; Hu, Jiayu <jiayu...@intel.com>; techbo...@dpdk.org; > >> >> tho...@monjalon.net; yangy...@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" > >> >> <mailto:konstantin.anan...@intel.com> 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 <mailto:yangy...@inspur.com> > >> >> >> --- > >> >> >> 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 > > Got it, thanks Jiayu, I'll send out v3 to fix all the comments. Is "return 0 > for the case ret == 1" ok? Before, this is still transmitted as a normal > packet, but it is dropped/freed if ret <0.
When no GSO happens, return 0 and pkts_out[] doesn't store input pkt. This design is OK for me. Thanks, Jiayu > > >> > > >> >> > >> > >> > >> > >> > >> > > > > > >
