DPDK patches and discussions
 help / color / mirror / Atom feed
From: yang_y_yi  <yang_y_yi@163.com>
To: "Jiayu Hu" <jiayu.hu@intel.com>
Cc: konstantin.ananyev@intel.com, dev@dpdk.org, techboard@dpdk.org,
	 thomas@monjalon.net, yangyi01@inspur.com
Subject: Re: [dpdk-dev] [PATCH v2] gso: fix free issue of mbuf gso segments attach to
Date: Mon, 26 Oct 2020 10:12:24 +0800 (CST)	[thread overview]
Message-ID: <1bb02f03.1777.17562ad96f2.Coremail.yang_y_yi@163.com> (raw)
In-Reply-To: <20201026020609.GA82482@NPG_DPDK_VIRTIO_jiayuhu_15.sh.intel.com>

At 2020-10-26 10:06:09, "Jiayu Hu" <jiayu.hu@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@intel.com>
>> wrote:
>> 
>> >> From: yang_y_yi <yang_y_yi@163.com>
>> >> Sent: Friday, October 23, 2020 2:18 PM
>> >> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>> >> Cc: dev@dpdk.org; Hu, Jiayu <jiayu.hu@intel.com>; 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" <mailto:konstantin.ananyev@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@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.

>> >
>> >>
>> 
>> 
>> 
>>  
>> 



  reply	other threads:[~2020-10-26  2:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22  6:51 yang_y_yi
2020-10-22 13:16 ` Ananyev, Konstantin
2020-10-22 15:33   ` Ananyev, Konstantin
2020-10-23  0:57     ` Hu, Jiayu
2020-10-23 13:23       ` yang_y_yi
2020-10-23 13:21     ` yang_y_yi
2020-10-23 13:18   ` yang_y_yi
2020-10-23 14:46     ` Ananyev, Konstantin
2020-10-26  0:57       ` yang_y_yi
2020-10-26  2:06         ` Jiayu Hu
2020-10-26  2:12           ` yang_y_yi [this message]
2020-10-26  6:16             ` Jiayu Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1bb02f03.1777.17562ad96f2.Coremail.yang_y_yi@163.com \
    --to=yang_y_yi@163.com \
    --cc=dev@dpdk.org \
    --cc=jiayu.hu@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=yangyi01@inspur.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).