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 0/4] Defer skb allocation for both mergeable buffers and big packets in virtio_net
Date: Mon, 14 Dec 2009 11:59:57 -0800 [thread overview]
Message-ID: <1260820797.8716.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20091213101907.GA6789@redhat.com>
On Sun, 2009-12-13 at 12:19 +0200, Michael S. Tsirkin wrote:
>
> Shirley, some advice on packaging patches
> that I hope will be helpful:
>
> You did try to split up the patch logically,
> and it's better than a single huge patch, but it
> can be better. For example, you add static functions
> in one patch and use them in another patch,
> this works well for new APIs which are documented
> so you can understand from the documentation
> what function should do, but not for internal, static functions:
> one ends up looking at usage, going back to implementation,
> back to usage, each time switching between patches.
>
> One idea on how to split up the patch set better:
> - add new "destroy" API and supply documentation
> - switch current implementation over to use destroy API
> - split current implementation into subfunctions
> handling mergeable/big cases
> - convert functions to use deferred allocation
> [would be nice to convert mergeable/big separately,
> but I am not sure this is possible while keeping
> patchset bisectable]
>
> Some suggestions on formatting:
> - keep patch names short, and prefix with module name,
> not patchset name, so that git summaries look nicer. E.g.
> Defer skb allocation -- add destroy buffers function for virtio
> Would be better "virtio: add destroy buffers function".
> - please supply commit message with some explanation
> and motivation that will help someone looking
> at git history, without background from mailing list.
> E.g.
> "Add "destroy" vq API that returns all posted
> buffers back to caller. This makes it possible
> to avoid tracking buffers in callers to free
> them on vq teardown. Will be used by deferred
> skb allocation patch.".
> - Use "---" to separate description from text,
> and generally make patch acceptable to git am.
> It is a good idea to use git to generate patches,
> for example with git format-patch.
> I usually use it with --numbered --thread --cover-letter.
>
> > Guest virtio_net receives packets from its pre-allocated vring
> > buffers, then it delivers these packets to upper layer protocols
> > as skb buffs. So it's not necessary to pre-allocate skb for each
> > mergable buffer, then frees it when it's useless.
> > This patch has deferred skb allocation when receiving packets for
> > both big packets and mergeable buffers. It reduces skb
> pre-allocations
> > and skb_frees.
>
> E.g. the above should go into commit message for the virtio net
> part of patchset.
Nice comments, will include them.
> I think you need to base your patch on Dave's net-next,
> it's too late to put it in 2.6.32, or even 2.6.33.
> It also should probably go in through Dave's tree because virtio part
> of
> patch is very small, while most of it deals with net/virtio_net.
> > Tests have been done for small packets, big packets
> > and mergeable buffers.
> >
> > The single netperf TCP_STREAM performance improved for host to
> guest.
> > It also reduces UDP packets drop rate.
>
>
> BTW, any numbers? Also, 2.6.32 has regressed as compared to 2.6.31.
> Did you try with Sridhar Samudrala's patch from net-next applied
> that reportedly fixes this?
Ok, I will run Dave's net-next tree.
Thanks
Shirley
prev parent reply other threads:[~2009-12-14 20:00 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
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 [this message]
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=1260820797.8716.2.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 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.