From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Chris Lew <quic_clew@quicinc.com>,
bjorn.andersson@linaro.org, linux-remoteproc@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] Introduction of rpmsg_rx_done
Date: Wed, 27 Jul 2022 11:25:29 -0600 [thread overview]
Message-ID: <20220727172529.GD199805@p14s> (raw)
In-Reply-To: <CANLsYkxBZ+4its5sUPJExnenU8dgttcUwdsBApwC_nYMLmsmHg@mail.gmail.com>
On Mon, Jul 18, 2022 at 10:54:30AM -0600, Mathieu Poirier wrote:
> On Mon, 18 Jul 2022 at 02:26, Arnaud POULIQUEN
> <arnaud.pouliquen@foss.st.com> wrote:
> >
> > Hello Chris,
> >
> > On 6/8/22 03:16, Chris Lew wrote:
> > > This series proposes an implementation for the rpmsg framework to do
> > > deferred cleanup of buffers provided in the rx callback. The current
> > > implementation assumes that the client is done with the buffer after
> > > returning from the rx callback.
> > >
> > > In some cases where the data size is large, the client may want to
> > > avoid copying the data in the rx callback for later processing. This
> > > series proposes two new facilities for signaling that they want to
> > > hold on to a buffer after the rx callback.
> > > They are:
> > > - New API rpmsg_rx_done() to tell the rpmsg framework the client is
> > > done with the buffer
> > > - New return codes for the rx callback to signal that the client will
> > > hold onto a buffer and later call rpmsg_rx_done()
> > >
> > > This series implements the qcom_glink_native backend for these new
> > > facilities.
> >
> > The API you proposed seems to me quite smart and adaptable to the rpmsg
> > virtio backend.
> >
> > My main concern is about the release of the buffer when the endpoint
> > is destroyed.
> >
> > Does the buffer release should be handled by each services or by the
> > core?
> >
> > I wonder if the buffer list could be managed by the core part by adding
> > the list in the rpmsg_endpoint structure. On destroy the core could call
> > the rx_done for each remaining buffers in list...
Arnaud has a valid point, though rpmst_endpoint_ops::destroy_ept() is there for
this kind of cleanup (and this patchet is making use of it).
I think we can leave things as they are now and consider moving to the core if
we see a trend in future submissions.
Thanks,
Mathieu
> >
> > I let Bjorn and Mathieu advise on this...
>
> Thanks for taking a look Arnaud. I'll get to this sortly.
>
> >
> > Thanks,
> > Arnaud
> >
> > >
> > > Chris Lew (4):
> > > rpmsg: core: Add rx done hooks
> > > rpmsg: char: Add support to use rpmsg_rx_done
> > > rpmsg: glink: Try to send rx done in irq
> > > rpmsg: glink: Add support for rpmsg_rx_done
> > >
> > > drivers/rpmsg/qcom_glink_native.c | 112 ++++++++++++++++++++++++++++++--------
> > > drivers/rpmsg/rpmsg_char.c | 50 ++++++++++++++++-
> > > drivers/rpmsg/rpmsg_core.c | 20 +++++++
> > > drivers/rpmsg/rpmsg_internal.h | 1 +
> > > include/linux/rpmsg.h | 24 ++++++++
> > > 5 files changed, 183 insertions(+), 24 deletions(-)
> > >
next prev parent reply other threads:[~2022-07-27 18:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-08 1:16 [PATCH 0/4] Introduction of rpmsg_rx_done Chris Lew
2022-06-08 1:16 ` [PATCH 1/4] rpmsg: core: Add rx done hooks Chris Lew
2022-07-18 8:31 ` Arnaud POULIQUEN
2022-07-27 17:16 ` Mathieu Poirier
2022-06-08 1:16 ` [PATCH 2/4] rpmsg: char: Add support to use rpmsg_rx_done Chris Lew
2022-07-27 17:18 ` Mathieu Poirier
2022-06-08 1:16 ` [PATCH 3/4] rpmsg: glink: Try to send rx done in irq Chris Lew
2022-06-08 1:16 ` [PATCH 4/4] rpmsg: glink: Add support for rpmsg_rx_done Chris Lew
2022-07-27 17:21 ` Mathieu Poirier
2022-07-18 8:26 ` [PATCH 0/4] Introduction of rpmsg_rx_done Arnaud POULIQUEN
2022-07-18 16:54 ` Mathieu Poirier
2022-07-27 17:25 ` Mathieu Poirier [this message]
2022-07-26 17:51 ` Mathieu Poirier
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=20220727172529.GD199805@p14s \
--to=mathieu.poirier@linaro.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=quic_clew@quicinc.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.