From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, netdev@vger.kernel.org, rick.jones2@hp.com,
virtualization@lists.linux-foundation.org,
levinsasha928@gmail.com, pbonzini@redhat.com,
Tom Herbert <therbert@google.com>
Subject: Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
Date: Wed, 12 Sep 2012 09:59:16 +0930 [thread overview]
Message-ID: <87txv4ccdf.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120910061629.GC16819@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> In other words RPS is a hack to speed up networking on cheapo
> hardware, this is one of the reasons it is off by default.
> Good hardware has multiple receive queues.
> We can implement a good one so we do not need RPS.
>
> Also not all guest OS-es support RPS.
>
> Does this clarify?
Ok, thanks.
BTW, I found a better description by Tom Herbert, BTW:
https://code.google.com/p/kernel/wiki/NetScalingGuide
Now, I find the description of VIRTIO_NET_CTRL_STEERING_RX_FOLLOWS_TX
confusing:
1) AFAICT it turns on multiqueue rx, with no semantics attached.
I have no idea why it's called what it is. Why?
2) We've said we can remove steering methods, but we haven't actually
defined any, as we've left it completely open.
If I were a driver author, it leaves me completely baffled on how to
implement the spec :(
What are we actually planning to implement at the moment?
>For best performance, packets from a single connection should utilize
>the paired transmit and receive queues from the same virtqueue pair;
>for example both transmitqN and receiveqN. This rule makes it possible
>to optimize processing on the device side, but this is not a hard
>requirement: devices should function correctly even when this rule is
>not followed.
Why is this true? I don't actually see why the queues are in pairs at
all; are tx and rx not completely independent? So why does it matter?
>> When the steering rule is modified, some packets can still be
>> outstanding in one or more of the virtqueues. Device is not required
>> to wait for these packets to be consumed before delivering packets
>> using the new streering rule. Drivers modifying the steering rule at
>> a high rate (e.g. adaptively in response to changes in the workload)
>> are recommended to complete processing of the receive queue(s)
>> utilized by the original steering before processing any packets
>> delivered by the modified steering rule.
How can this be done? This isn't actually possible without taking the
queue down, since more packets are incoming.
Cheers,
Rusty.
next prev parent reply other threads:[~2012-09-12 0:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-09 13:03 [PATCHv4] virtio-spec: virtio network device multiqueue support Michael S. Tsirkin
2012-09-10 2:12 ` Rusty Russell
2012-09-10 6:16 ` Michael S. Tsirkin
2012-09-10 6:27 ` Michael S. Tsirkin
2012-09-10 6:33 ` Michael S. Tsirkin
2012-09-10 11:00 ` Jason Wang
2012-09-12 5:49 ` Rusty Russell
2012-09-12 7:57 ` Michael S. Tsirkin
2012-09-12 14:40 ` Tom Herbert
2012-09-12 14:40 ` Tom Herbert
2012-09-12 19:11 ` Ben Hutchings
2012-09-12 14:38 ` Tom Herbert
2012-09-19 1:40 ` Rusty Russell
2012-09-19 6:12 ` Michael S. Tsirkin
2012-09-12 0:29 ` Rusty Russell [this message]
2012-09-10 18:39 ` Rick Jones
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=87txv4ccdf.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.jones2@hp.com \
--cc=therbert@google.com \
--cc=virtualization@lists.linux-foundation.org \
/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.