Re: [PATCHv4] virtio-spec: virtio network device multiqueue support

"Michael S. Tsirkin" [off-list ref] 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?

quoted

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.