From: Thomas Monjalon <thomas@monjalon.net>
To: "yang_y_yi@163.com" <yang_y_yi@163.com>,
"yangyi01@inspur.com" <yangyi01@inspur.com>
Cc: "techboard@dpdk.org" <techboard@dpdk.org>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
dev@dpdk.org, "dev@dpdk.org" <dev@dpdk.org>,
"Hu, Jiayu" <jiayu.hu@intel.com>,
olivier.matz@6wind.com
Subject: Re: [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to
Date: Tue, 03 Nov 2020 22:34:52 +0100 [thread overview]
Message-ID: <2280167.6YWU9ATIUA@thomas> (raw)
In-Reply-To: <1680723.gEWeqp86JR@thomas>
29/10/2020 22:39, Thomas Monjalon:
> I don't have a clear opinion on this patch.
> Techboard members, ping for feedbacks.
> If no objection, I will merge it soon, but I would prefer having more acks.
>
>
> 27/10/2020 20:55, Ananyev, Konstantin:
> > From: yang_y_yi@163.com <yang_y_yi@163.com>
> > > From: Yi Yang <yangyi01@inspur.com>
> > >
> > > 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.
> > >
> > > This commit changed rte_gso_segment in functional behavior
> > > and return value, so the application must take appropriate
> > > actions according to return values, "ret < 0" means it
> > > should free and drop 'pkt', "ret == 0" means 'pkt' isn't
> > > GSOed but 'pkt' can be transimmitted as a normal packet,
> > > "ret > 0" means 'pkt' has been GSOed into two or multiple
> > > segments, it should use "pkts_out" to transmit these
> > > segments. The application must free 'pkt' after call
> > > rte_gso_segment when return value isn't equal to 0.
> >
> > Tech-board members: this is not a formal API breakage,
> > but it is a functional change (i.e. all code that uses that API will need to be changed).
> > There was no deprecation note in advance.
> > So please provide your input: are you ok with such change or not.
> >
> > I am ok with the proposed changes.
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> [...]
> > > packets in software. Note however, that GSO is implemented as a standalone
> > > library, and not via a 'fallback' mechanism (i.e. for when TSO is unsupported
> > > in the underlying hardware); that is, applications must explicitly invoke the
> > > -GSO library to segment packets. The size of GSO segments ``(segsz)`` is
> > > -configurable by the application.
> > > +GSO library to segment packets, they also must call ``rte_pktmbuf_free()`` to
> > > +free mbuf GSO segments attach to after calling ``rte_gso_segment()``. The size
> > > +of GSO segments ``(segsz)`` is configurable by the application.
> [...]
> > > #. Invoke the GSO segmentation API, ``rte_gso_segment()``.
> > >
> > > +#. Call ``rte_pktmbuf_free()`` to free mbuf ``rte_gso_segment()`` segments.
> [...]
> > > --- a/doc/guides/rel_notes/release_20_11.rst
> > > +++ b/doc/guides/rel_notes/release_20_11.rst
> > > @@ -543,6 +543,13 @@ API Changes
> > > +* **Changed ``rte_gso_segment`` in functional behavior and return value.**
> > > +
> > > + * Don't save pkt to pkts_out[0] if it isn't GSOed in case of ret == 1.
> > > + * Return 0 instead of 1 for the above case.
> > > + * ``rte_gso_segment`` won't free pkt no matter whether it is GSOed, the
> > > + application has responsibility to free it after call ``rte_gso_segment``.
> [...]
> > > --- a/lib/librte_gso/rte_gso.h
> > > +++ b/lib/librte_gso/rte_gso.h
> > > - * If the input packet is GSO'd, its mbuf refcnt reduces by 1. Therefore,
> > > - * when all GSO segments are freed, the input packet is freed automatically.
> > > + * If the input packet is GSO'd, all the indirect segments are attached to the
> > > + * input packet.
> > > + *
> > > + * rte_gso_segment() will not free the input packet no matter whether it is
> > > + * GSO'd or not, the application should free it after call rte_gso_segment().
> > > *
> > > * If the memory space in pkts_out or MBUF pools is insufficient, this
> > > * function fails, and it returns (-1) * errno. Otherwise, GSO succeeds,
> > > @@ -109,6 +112,7 @@ struct rte_gso_ctx {
> > > *
> > > * @return
> > > * - The number of GSO segments filled in pkts_out on success.
> > > + * - Return 0 if it needn't GSOed.
> > > * - Return -ENOMEM if run out of memory in MBUF pools.
> > > * - Return -EINVAL for invalid parameters.
> > > */
Applied with formatting and english improvements, thanks.
next prev parent reply other threads:[~2020-11-03 21:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 6:47 [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to yang_y_yi
2020-10-27 19:55 ` Ananyev, Konstantin
2020-10-29 21:39 ` Thomas Monjalon
2020-11-03 21:34 ` Thomas Monjalon [this message]
2020-11-04 0:35 ` yang_y_yi
2020-10-28 0:51 ` Hu, Jiayu
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=2280167.6YWU9ATIUA@thomas \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=jiayu.hu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=olivier.matz@6wind.com \
--cc=techboard@dpdk.org \
--cc=yang_y_yi@163.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.