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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Sep 2012 09:59:16 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org,
	netdev@...r.kernel.org, Jason Wang <jasowang@...hat.com>,
	pbonzini@...hat.com, levinsasha928@...il.com, rick.jones2@...com,
	Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCHv4] virtio-spec: virtio network device multiqueue support

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