From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH RFC v2] ptr_ring: add ptr_ring_unconsume
Date: Wed, 26 Apr 2017 18:54:47 +0300 [thread overview]
Message-ID: <20170426184956-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ce6e1816-e3e0-4e6b-b017-05cfc54a0170@redhat.com>
On Wed, Apr 26, 2017 at 05:09:42PM +0800, Jason Wang wrote:
>
>
> On 2017年04月25日 00:01, Michael S. Tsirkin wrote:
> > Applications that consume a batch of entries in one go
> > can benefit from ability to return some of them back
> > into the ring.
> >
> > Add an API for that - assuming there's space. If there's no space
> > naturally can't do this and have to drop entries, but this implies ring
> > is full so we'd likely drop some anyway.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > Jason, if you add this and unconsume the outstanding packets
> > on backend disconnect, vhost close and reset, I think
> > we should apply your patch even if we don't yet know 100%
> > why it helps.
> >
> > changes from v1:
> > - fix up coding style issues reported by Sergei Shtylyov
> >
> >
> > include/linux/ptr_ring.h | 56 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> > index 783e7f5..902afc2 100644
> > --- a/include/linux/ptr_ring.h
> > +++ b/include/linux/ptr_ring.h
> > @@ -457,6 +457,62 @@ static inline int ptr_ring_init(struct ptr_ring *r, int size, gfp_t gfp)
> > return 0;
> > }
> > +/*
> > + * Return entries into ring. Destroy entries that don't fit.
> > + *
> > + * Note: this is expected to be a rare slow path operation.
> > + *
> > + * Note: producer lock is nested within consumer lock, so if you
> > + * resize you must make sure all uses nest correctly.
> > + * In particular if you consume ring in interrupt or BH context, you must
> > + * disable interrupts/BH when doing so.
> > + */
> > +static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
> > + void (*destroy)(void *))
> > +{
> > + unsigned long flags;
> > + int head;
> > +
> > + spin_lock_irqsave(&r->consumer_lock, flags);
> > + spin_lock(&r->producer_lock);
> > +
> > + if (!r->size)
> > + goto done;
> > +
> > + /*
> > + * Clean out buffered entries (for simplicity). This way following code
> > + * can test entries for NULL and if not assume they are valid.
> > + */
> > + head = r->consumer_head - 1;
> > + while (likely(head >= r->consumer_tail))
> > + r->queue[head--] = NULL;
> > + r->consumer_tail = r->consumer_head;
> > +
> > + /*
> > + * Go over entries in batch, start moving head back and copy entries.
> > + * Stop when we run into previously unconsumed entries.
> > + */
> > + while (n--) {
Maybe this is called with n = 0?
Should be while (n-- > 0) I guess so n = 0 is valid.
> > + head = r->consumer_head - 1;
> > + if (head < 0)
> > + head = r->size - 1;
> > + if (r->queue[head]) {
> > + /* This batch entry will have to be destroyed. */
> > + ++n;
> > + goto done;
> > + }
> > + r->queue[head] = batch[n];
> > + r->consumer_tail = r->consumer_head = head;
>
> Looks like something wrong here (bad page state reported), uncomment the
> above while()
I guess you mean comment out?
> solving the issue. But after staring it for a while I didn't
> find anything interesting, maybe you have some idea on this?
>
> Thanks
Add tracing to see what's going on?
>
> > + }
> > +
> > +done:
> > + /* Destroy all entries left in the batch. */
> > + while (n--)
> > + destroy(batch[n]);
> > + spin_unlock(&r->producer_lock);
> > + spin_unlock_irqrestore(&r->consumer_lock, flags);
> > +}
> > +
> > static inline void **__ptr_ring_swap_queue(struct ptr_ring *r, void **queue,
> > int size, gfp_t gfp,
> > void (*destroy)(void *))
next prev parent reply other threads:[~2017-04-26 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 16:01 [PATCH RFC v2] ptr_ring: add ptr_ring_unconsume Michael S. Tsirkin
2017-04-26 9:09 ` Jason Wang
2017-04-26 15:54 ` Michael S. Tsirkin [this message]
2017-05-09 13:26 ` Michael S. Tsirkin
2017-05-10 2:01 ` Jason Wang
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=20170426184956-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.