"Michael S. Tsirkin" <mst@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
