All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tom Herbert <therbert@google.com>
Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org, rick.jones2@hp.com,
	virtualization@lists.linux-foundation.org,
	levinsasha928@gmail.com, pbonzini@redhat.com
Subject: Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
Date: Wed, 19 Sep 2012 11:10:10 +0930	[thread overview]
Message-ID: <87wqzqpz7p.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CA+mtBx_Kjp62UYJs-7OSFsFKndx6H1oOkuD8U3ooAUuR1PMF=Q@mail.gmail.com>

Tom Herbert <therbert@google.com> writes:
> On Tue, Sep 11, 2012 at 10:49 PM, Rusty Russell <rusty@rustcorp.com.au>wrote:
>> Perhaps Tom can explain how we avoid out-of-order receive for the
>> accelerated RFS case?  It's not clear to me, but we need to be able to
>> do that for virtio-net if it implements accelerated RFS.
>
> AFAIK ooo RX is possible with accelerated RFS.  We have an algorithm that
> prevents this for RFS case by deferring a migration to a new queue as long
> as it's possible that a flow might have outstanding packets on the old
> queue.  I suppose this could be implemented in the device for the HW
> queues, but I don't think it would be easy to cover all cases where packets
> were already in transit to the host or other cases where host and device
> queues are out of sync.

Having gone to such great lengths to avoid ooo for RFS, I don't think
DaveM would be happy if we allow it for virtio_net.

So, how *would* we implement such a thing for a "hardware" device?  What
if the device will only change the receive queue if the old receive
queue is empty?

Cheers,
Rusty.

  reply	other threads:[~2012-09-19  1:40 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 [this message]
2012-09-19  6:12                 ` Michael S. Tsirkin
2012-09-12  0:29     ` Rusty Russell
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=87wqzqpz7p.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.