From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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, 19 Sep 2012 09:12:49 +0300 [thread overview]
Message-ID: <20120919061249.GA24564@redhat.com> (raw)
In-Reply-To: <87wqzqpz7p.fsf@rustcorp.com.au>
On Wed, Sep 19, 2012 at 11:10:10AM +0930, Rusty Russell wrote:
> 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.
>
I think that would do it in most cases. Or if we want to be more
exact we could delay switching a specific flow until no
outstanding rx packets for this flow. Not sure it's worth the
hassle.
--
MST
next prev parent reply other threads:[~2012-09-19 6:12 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 [this message]
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=20120919061249.GA24564@redhat.com \
--to=mst@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.jones2@hp.com \
--cc=rusty@rustcorp.com.au \
--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.