From: Rusty Russell <rusty@rustcorp•com.au>
To: "Michael S. Tsirkin" <mst@redhat•com>, linux-kernel@vger•kernel.org
Cc: Carsten Otte <cotte@de•ibm.com>,
Christian Borntraeger <borntraeger@de•ibm.com>,
linux390@de•ibm.com, Martin Schwidefsky <schwidefsky@de•ibm.com>,
Heiko Carstens <heiko.carstens@de•ibm.com>,
Shirley Ma <xma@us•ibm.com>,
lguest@lists•ozlabs.org,
virtualization@lists•linux-foundation.org,
netdev@vger•kernel.org, linux-s390@vger•kernel.org,
kvm@vger•kernel.org, Krishna Kumar <krkumar2@in•ibm.com>,
Tom Lendacky <tahm@linux•vnet.ibm.com>,
steved@us•ibm.com, habanero@linux•vnet.ibm.com
Subject: Re: [PATCHv2 RFC 4/4] Revert "virtio: make add_buf return capacity remaining:
Date: Wed, 08 Jun 2011 09:49:56 +0930 [thread overview]
Message-ID: <877h8xgonn.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20110607155457.GA17436@redhat.com>
On Tue, 7 Jun 2011 18:54:57 +0300, "Michael S. Tsirkin" <mst@redhat•com> wrote:
> On Thu, Jun 02, 2011 at 06:43:25PM +0300, Michael S. Tsirkin wrote:
> > This reverts commit 3c1b27d5043086a485f8526353ae9fe37bfa1065.
> > The only user was virtio_net, and it switched to
> > min_capacity instead.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat•com>
>
> It turns out another place in virtio_net: receive
> buf processing - relies on the old behaviour:
>
> try_fill_recv:
> do {
> if (vi->mergeable_rx_bufs)
> err = add_recvbuf_mergeable(vi, gfp);
> else if (vi->big_packets)
> err = add_recvbuf_big(vi, gfp);
> else
> err = add_recvbuf_small(vi, gfp);
>
> oom = err == -ENOMEM;
> if (err < 0)
> break;
> ++vi->num;
> } while (err > 0);
>
> The point is to avoid allocating a buf if
> the ring is out of space and we are sure
> add_buf will fail.
>
> It works well for mergeable buffers and for big
> packets if we are not OOM. small packets and
> oom will do extra get_page/put_page calls
> (but maybe we don't care).
>
> So this is RX, I intend to drop it from this patchset and focus on the
> TX side for starters.
We could do some hack where we get the capacity, and estimate how many
packets we need to fill it, then try to do that many.
I say hack, because knowing whether we're doing indirect buffers is a
layering violation. But that's life when you're trying to do
microoptimizations.
Cheers,
Rusty.
next prev parent reply other threads:[~2011-06-08 0:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 15:42 [PATCHv2 RFC 0/4] virtio and vhost-net capacity handling Michael S. Tsirkin
[not found] ` <cover.1307029008.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-06-02 15:42 ` [PATCHv2 RFC 1/4] virtio_ring: add capacity check API Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 2/4] virtio_net: fix tx capacity checks using new API Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 3/4] virtio_net: limit xmit polling Michael S. Tsirkin
2011-06-02 18:09 ` Sridhar Samudrala
[not found] ` <1307038193.2321.38.camel-gzECXbv5Qf5llG67XfQwVQGz3MnDiSnoQQ4Iyu8u01E@public.gmane.org>
2011-06-02 19:23 ` Michael S. Tsirkin
[not found] ` <a80199422de16ae355e56ee1b2abc9b2bf91a7f6.1307029009.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-06-07 15:59 ` Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 4/4] Revert "virtio: make add_buf return capacity remaining: Michael S. Tsirkin
[not found] ` <7572d6fb81181e349af4a8b203ea0977f6e91ae1.1307029009.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-06-07 15:54 ` Michael S. Tsirkin
2011-06-08 0:19 ` Rusty Russell [this message]
2011-06-02 17:17 ` [PATCHv2 RFC 0/4] virtio and vhost-net capacity handling Michael S. Tsirkin
[not found] ` <20110602171721.GA13215-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-06-06 3:39 ` Rusty Russell
2011-06-07 16:08 ` Michael S. Tsirkin
2011-06-13 13:32 ` Krishna Kumar2
[not found] ` <OFE36F9C2B.43D9DB04-ON652578AE.0048E1AB-652578AE.004A1462-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
2011-06-13 13:35 ` Michael S. Tsirkin
[not found] ` <20110613133513.GA29884-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-06-13 13:44 ` Krishna Kumar2
2011-06-13 13:38 ` Krishna Kumar2
2011-06-19 8:53 ` Michael S. Tsirkin
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=877h8xgonn.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=borntraeger@de$(echo .)ibm.com \
--cc=cotte@de$(echo .)ibm.com \
--cc=habanero@linux$(echo .)vnet.ibm.com \
--cc=heiko.carstens@de$(echo .)ibm.com \
--cc=krkumar2@in$(echo .)ibm.com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=lguest@lists$(echo .)ozlabs.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=linux390@de$(echo .)ibm.com \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=schwidefsky@de$(echo .)ibm.com \
--cc=steved@us$(echo .)ibm.com \
--cc=tahm@linux$(echo .)vnet.ibm.com \
--cc=virtualization@lists$(echo .)linux-foundation.org \
--cc=xma@us$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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