netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Shirley Ma <mashirle@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	netdev@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [PATCH v2 1/4] Defer skb allocation -- add destroy buffers function for virtio
Date: Wed, 16 Dec 2009 00:40:02 +0200	[thread overview]
Message-ID: <20091215224002.GA27034@redhat.com> (raw)
In-Reply-To: <200912160906.12430.rusty@rustcorp.com.au>

On Wed, Dec 16, 2009 at 09:06:12AM +1030, Rusty Russell wrote:
> On Tue, 15 Dec 2009 06:52:53 am Michael S. Tsirkin wrote:
> > On Mon, Dec 14, 2009 at 12:08:05PM -0800, Shirley Ma wrote:
> > > Hello Michael,
> > > 
> > > I agree with the comments (will have two patches instead of 4 based on
> > > Rusty's comments) except below one.
> > > 
> > > On Sun, 2009-12-13 at 12:26 +0200, Michael S. Tsirkin wrote:
> > > > That said - do we have to use a callback?
> > > > I think destroy_buf which returns data pointer,
> > > > and which we call repeatedly until we get NULL
> > > > or error, would be an a better, more flexible API.
> > > > This is not critical though.
> > > 
> > > The reason to use this is because in virtio_net remove, it has
> > > BUG_ON(vi->num != 0), which will be consistent with small skb packet. If
> > > we use NULL, error then we lose the track for vi->num, since we don't
> > > know how many buffers have been passed to ULPs or still unused.
> > > 
> > > Thanks
> > > Shirley
> > 
> > I dont insist, but my idea was
> > 
> > for (;;) {
> > 	b = vq->destroy(vq);
> > 	if (!b)
> > 		break;
> > 	--vi->num;
> > 	put_page(b);
> > }
> 
> In this case it should be called "get_unused_buf" or something.  But I like
> Shirley's approach here; destroy (with callback) accurately reflects the only
> time this can be validly used.
> 
> Cheers,
> Rusty.

I guess the actual requirement is that device must be
inactive.

As I said this is fine with me as well.
But I think the callback should get vq pointer besides the
data pointer, so that it can e.g. find the device if it needs to.
In case of virtio net this makes it possible
to decrement the outstanding skb counter in the callback.
Makes sense?

-- 
MST

  reply	other threads:[~2009-12-15 22:40 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-20  6:09 [PATCH 0/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net Shirley Ma
2009-11-23  0:53 ` Rusty Russell
2009-11-23  8:51   ` Mark McLoughlin
2009-12-08 12:21   ` Michael S. Tsirkin
2009-12-11 12:28     ` [PATCH v2 0/4] " Shirley Ma
2009-12-11 12:33       ` [PATCH v2 1/4] Defer skb allocation -- add destroy buffers function for virtio Shirley Ma
2009-12-13 10:26         ` Michael S. Tsirkin
2009-12-14 20:08           ` Shirley Ma
2009-12-14 20:22             ` Michael S. Tsirkin
2009-12-14 23:22               ` Shirley Ma
2009-12-15 10:57                 ` Michael S. Tsirkin
2009-12-15 22:36               ` Rusty Russell
2009-12-15 22:40                 ` Michael S. Tsirkin [this message]
2009-12-16  5:04                   ` Rusty Russell
2009-12-14  3:25         ` Rusty Russell
2009-12-14 22:09           ` Shirley Ma
2009-12-11 12:43       ` [PATCH v2 2/4] Defer skb allocation -- new skb_set calls & chain pages in virtio_net Shirley Ma
2009-12-13 11:24         ` Michael S. Tsirkin
2009-12-14 21:23           ` Shirley Ma
2009-12-15 11:21             ` Michael S. Tsirkin
2009-12-14  6:54         ` Rusty Russell
2009-12-14 22:10           ` Shirley Ma
2009-12-11 12:46       ` PATCH v2 3/4] Defer skb allocation -- new recvbuf alloc & receive calls Shirley Ma
2009-12-13 11:43         ` Michael S. Tsirkin
2009-12-14 22:08           ` Shirley Ma
2009-12-15  0:37             ` Shirley Ma
2009-12-15 11:33             ` Michael S. Tsirkin
2009-12-15 16:25               ` Shirley Ma
2009-12-15 16:39                 ` Michael S. Tsirkin
2009-12-15 18:42                   ` [RFC PATCH] Subject: virtio: Add unused buffers detach from vring Shirley Ma
2009-12-15 18:47                     ` Michael S. Tsirkin
2009-12-15 19:08                       ` Shirley Ma
2009-12-15 19:14                       ` Shirley Ma
2009-12-15 21:14                         ` Michael S. Tsirkin
2009-12-11 12:49       ` [PATCH v2 4/4] Defer skb allocation -- change allocation & receiving in recv path Shirley Ma
2009-12-13 11:08         ` Michael S. Tsirkin
2009-12-15  8:43           ` Shirley Ma
2009-12-13 10:19       ` [PATCH v2 0/4] Defer skb allocation for both mergeable buffers and big packets in virtio_net Michael S. Tsirkin
2009-12-14 19:59         ` Shirley Ma

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=20091215224002.GA27034@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mashirle@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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).