[dpdk-dev] [PATCH v2] gso: fix free issue of mbuf gso segments attach to

[Jiayu Hu]

On Mon, Oct 26, 2020 at 10:12:24AM +0800, yang_y_yi wrote:
> At 2020-10-26 10:06:09, "Jiayu Hu" <jiayu.hu at 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.ananyev at intel.com>
> >> wrote:
> >>
> >> >> From: yang_y_yi <yang_y_yi at 163.com>
> >> >> Sent: Friday, October 23, 2020 2:18 PM
> >> >> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> >> >> Cc: dev at dpdk.org; Hu, Jiayu <jiayu.hu at intel.com>; techboard at dpdk.org; thomas at monjalon.net; yangyi01 at 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.ananyev at 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:yangyi01 at 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
> 
> >> >
> >> >>
> >>
> >>
> >>
> >>
> >>
> 
> 
> 
> 
>  
>