Thread (1 message) 1 message, 1 author, 2011-06-08

Re: [PATCHv2 RFC 4/4] Revert "virtio: make add_buf return capacity remaining:

From: Rusty Russell <hidden>
Date: 2011-06-08 00:19:56

On Tue, 7 Jun 2011 18:54:57 +0300, "Michael S. Tsirkin" [off-list ref] wrote:
On Thu, Jun 02, 2011 at 06:43:25PM +0300, Michael S. Tsirkin wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help