netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shirley Ma <mashirle@us.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	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 3/4] Defer skb allocation -- new recvbuf alloc & receive calls
Date: Tue, 15 Dec 2009 08:25:20 -0800	[thread overview]
Message-ID: <1260894320.4387.64.camel@localhost.localdomain> (raw)
In-Reply-To: <20091215113327.GC13110@redhat.com>

On Tue, 2009-12-15 at 13:33 +0200, Michael S. Tsirkin wrote:
> So what I would suggest is, have function
> that just copies part of skb, and have
> caller open-code allocating the skb and free up
> pages as necessary.
Yes, the updated patch has changed the function.

> What I am asking is why do we add skb in vi->recv.
> Can't we use vq destoy hack here as well?
Yes, I removed recv queue skb link totally in the updated patch.

> > One is for big packet virtio_net_hdr, one is for goodcopy skb.
> 
> 
> Maybe put this in a comment then.
Ok, will do.

> 
> I mean the for loop: can i be for(i = 0, ..., ++i) just as well?
> Why do you start at the end of buffer and decrement?

Are asking why reverse order for new page to sg? The reason is we link
the new page in first, and only maintain the first pointer. So the most
recent new page should be related to sg[0], if we put the new page in
the last, then we need to travel the page list to get last pointer. Am I
missing your point here?

Thanks
Shirley 


  reply	other threads:[~2009-12-15 16:25 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
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 [this message]
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=1260894320.4387.64.camel@localhost.localdomain \
    --to=mashirle@us.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.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).