All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Bug 1286253 <1286253@bugs.launchpad.net>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1286253] [NEW] virtio-net acceleration features not set when plugged into backend dynamically
Date: Mon, 3 Mar 2014 14:48:33 +0200	[thread overview]
Message-ID: <20140303124833.GA6319@redhat.com> (raw)
In-Reply-To: <20140303123746.GD21055@stefanha-thinkpad.redhat.com>

On Mon, Mar 03, 2014 at 01:37:46PM +0100, Stefan Hajnoczi wrote:
> On Fri, Feb 28, 2014 at 05:40:19PM -0000, Mario Smarduch wrote:
> > When using indpendent transport and backend in this case virtio-net-
> > device transport, none of the acceleration features are set after guest
> > probes the transport the backend is plugged into. For virtio-net this
> > leads to low throughput/performance.  This holds true for  virtio-mmio,
> > PCI transports and most likely for others as well (CCW, S390) and other
> > backends
> > 
> > Command to run:
> > ./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \
> >       -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \
> >       -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \
> >       -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58"
> > 
> > For x86 same virtio command for network.
> 
> Can you explain in more detail?
> 
> The command-line looks sane.  The virtio-net-device instance should
> figure out the tap supports offloads.
> 
> Did you try adding a printf to virtio_net_get_features() to see why the
> offload features are not being detected?
> 
> Stefan

IIUC mmio does not set any feature bits, so you get the fallback behaviour:

$ git grep DEFINE_VIRTIO_NET_FEATURES
hw/s390x/s390-virtio-bus.c: DEFINE_VIRTIO_NET_FEATURES(VirtIOS390Device, host_featur
hw/s390x/virtio-ccw.c:    DEFINE_VIRTIO_NET_FEATURES(VirtioCcwDevice, host_features[0])
hw/virtio/virtio-pci.c:    DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),
include/hw/virtio/virtio-net.h:#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \

But it should work for pci, and certainly does for x86.


-- 
MST

  reply	other threads:[~2014-03-03 12:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 17:40 [Qemu-devel] [Bug 1286253] [NEW] virtio-net acceleration features not set when plugged into backend dynamically Mario Smarduch
2014-03-03 12:37 ` Stefan Hajnoczi
2014-03-03 12:48   ` Michael S. Tsirkin [this message]
2014-03-03 20:12     ` Mario Smarduch
2017-05-16 10:12 ` [Qemu-devel] [Bug 1286253] " Thomas Huth
2017-07-16  4:17 ` Launchpad Bug Tracker

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=20140303124833.GA6319@redhat.com \
    --to=mst@redhat.com \
    --cc=1286253@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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.