On Tue, Apr 7, 2015 at 6:54 PM, Alexander Graf ag...@suse.de wrote:
On 04/01/2015 10:15 AM, Jason Wang wrote:
This patch increases the maximum number of virtqueues for pci from 64
to 513. This will allow booting a virtio-net-pci device with 256 queue
pairs.
...
* configuration space */
On Thu, Feb 20, 2014 at 10:49:52AM +0100, Stefan Hajnoczi wrote:
On Wed, Feb 19, 2014 at 04:57:28PM +0100, Vincenzo Maffione wrote:
...
Please mention that in the commit description.
(I guess it's too late to give them a NETMAP_* prefix since defining D()
and RD() in a system header has a
and keep it simple.
cheers
luigi
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
On Fri, Feb 14, 2014 at 2:20 AM, Vincenzo Maffione v.maffi...@gmail.comwrote:
Yes, for sure we need to do a check.
However, this would involve - I think - some non-trivial modifications to
net/netmap.c, because without NS_MOREFRAG you cannot split a packet over
more netmap slots/descriptors
MORE support
This makes it easier to review and bisect.
Thanks,
Stefan
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
On Wed, Nov 20, 2013 at 10:41:22AM +0100, Paolo Bonzini wrote:
Il 20/11/2013 00:00, Luigi Rizzo ha scritto:
I recently found out that without kvm enabled, and especially
with -smp 2 or greater, qemu becomes incredibly slow
(to the point that you can see kernel messages in the
quest print
the scheduler, which happens right before and after the idle loop.
cheers
luigi
Cc: Richard Henderson r...@twiddle.net
Reported-by: Luigi Rizzo ri...@iet.unipi.it
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
target-i386/helper.h | 1 +
target-i386/misc_helper.c | 22
I recently found out that without kvm enabled, and especially
with -smp 2 or greater, qemu becomes incredibly slow
(to the point that you can see kernel messages in the
quest print one character at a time).
This happens with a Linux host (even with -smp 1)
and with FreeBSD host (in this case -smp
,
but there are other offending files that can be found with
grep '#!' scripts/*
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
---
scripts/acpi_extract.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py
index 22ea468..66c1b3e 100755
On Mon, Nov 4, 2013 at 9:41 AM, Anthony Liguori anth...@codemonkey.wswrote:
On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione v.maffi...@gmail.com
wrote:
This patch adds support for a network backend based on netmap.
netmap is a framework for high speed packet I/O. You can use it
to
On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote:
On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione v.maffi...@gmail.com
wrote:
This patch adds support for a network backend based on netmap
On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori anth...@codemonkey.wswrote:
On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote:
On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo ri...@iet.unipi.it
wrote
Can someone clarify what is the difference between the two methods
r
eceive_raw() and receive() in NetClientInfo ?
tap seems to be the only backend actually implementing receive_raw(),
but apart from prepending a vnet_hdr i cannot tell what is this for,
and whether receive_raw() is a custom addon
Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di
On Mon, Feb 18, 2013 at 1:50 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Feb 15, 2013 at 11:24:29AM +0100, Stefan Hajnoczi wrote:
On Thu, Feb 14, 2013 at 07:21:57PM +0100, Luigi Rizzo wrote:
CCed Michael Tsirkin
virtio-style network devices (where the producer and consumer
On Fri, Feb 15, 2013 at 11:24:29AM +0100, Stefan Hajnoczi wrote:
On Thu, Feb 14, 2013 at 07:21:57PM +0100, Luigi Rizzo wrote:
CCed Michael Tsirkin
virtio-style network devices (where the producer and consumer chase
each other through a shared memory block) can enter into a
bad
virtio-style network devices (where the producer and consumer chase
each other through a shared memory block) can enter into a
bad operating regime when the consumer is too fast.
I am hitting this case right now when virtio is used on top of the
netmap/VALE backend that I posted a few weeks ago:
On Fri, Feb 8, 2013 at 2:02 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Wed, Feb 06, 2013 at 03:23:41PM +0100, Luigi Rizzo wrote:
The following patch implements interrupt moderation registers
for the e1000 adapter. These feature is normally used by OS
drivers, and their implementation
On Fri, Feb 08, 2013 at 11:46:34AM +0100, Paolo Bonzini wrote:
Il 08/02/2013 11:20, Luigi Rizzo ha scritto:
...
I am happy to make this default to off. But it would be good if you could
actually give it a try. Note that linux and FreeBSD (and presumably windows)
do use moderation by default
On Fri, Feb 08, 2013 at 11:59:12AM +0100, Stefan Hajnoczi wrote:
...
http://info.iet.unipi.it/~luigi/papers/20130206-qemu.pdf is 404.
sorry, fixed now.
And, will resubmit a fixed patch with uninit and fixed braces in the
if() statement.
I am happy to make this default to off.
On Fri, Feb 08, 2013 at 12:52:12PM +0100, Paolo Bonzini wrote:
Il 07/02/2106 07:28, Luigi Rizzo ha scritto:
On Fri, Feb 08, 2013 at 11:46:34AM +0100, Paolo Bonzini wrote:
Il 08/02/2013 11:20, Luigi Rizzo ha scritto:
...
I am happy to make this default to off. But it would be good if you
) at
http://info.iet.unipi.it/~luigi/research.html#qemu
cheers
luigi
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
diff --git a/hw/e1000.c b/hw/e1000.c
index bb150c6..b4c0f4a 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -131,6 +131,10 @@ typedef struct E1000State_st {
} eecd_state;
QEMUTimer
To fix this i propose to introduce a new function net_hub_flush()
which is called when trying to flush a queue connected to a hub.
cheers
luigi
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
diff --git a/net/hub.c b/net/hub.c
index a24c9d1..df32074 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -338,3
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
diff --git a/net/hub.c b/net/hub.c
index a24c9d1..df32074 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -338,3 +338,17 @@ void net_hub_check_clients(void)
}
}
}
+
+bool net_hub_flush(NetClientState *nc)
+{
+NetHubPort *port
is dropped).
If documentation is correct, producers that submit a callback should
stop sending when their packet is queued, so there is no real risk
that the queue exceeds the max size by large values.
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
diff --git a/net/queue.c b/net/queue.c
index
On Thu, Jan 24, 2013 at 11:24 PM, Stefan Hajnoczi stefa...@gmail.comwrote:
On Thu, Jan 24, 2013 at 6:35 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
never mind, pilot error. in my test program i had swapped the
arguments to __builtin_memcpy(). With the correct ones,
__builtin_memcpy
On Fri, Jan 25, 2013 at 9:23 AM, Michael Tokarev m...@tls.msk.ru wrote:
---
v2: change __FUNCTION__ to __func__ according to qemu coding style
will do. However it does not seem a highly followed standard :)
lrizzo@netmap:~/work-qemu/qemu-git-head-20130121$ grep -r __FUNCTION__ . |
wc
On Thu, Jan 24, 2013 at 09:54:19AM +0100, Stefan Hajnoczi wrote:
On Wed, Jan 23, 2013 at 06:55:59PM -0800, Luigi Rizzo wrote:
On Wed, Jan 23, 2013 at 8:03 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
I'm even doubtful that it's always a win on FreeBSD. You have a
threshold to fall back
On Tue, Jan 22, 2013 at 2:50 PM, Anthony Liguori aligu...@us.ibm.comwrote:
Hi,
Thank you for submitting your patch series. checkpatch.pl has
detected that one or more of the patches in this series violate
the QEMU coding style.
If you believe this message was sent in error, please ignore
On Wed, Jan 23, 2013 at 12:10:55PM +0100, Stefan Hajnoczi wrote:
On Tue, Jan 22, 2013 at 08:12:15AM +0100, Luigi Rizzo wrote:
reposting a version without changes that implement bounded
queues in net/queue.c
Hi,
the attached patch implements a qemu backend for the netmap API
thus
On Wed, Jan 23, 2013 at 02:03:17PM +0100, Stefan Hajnoczi wrote:
On Wed, Jan 23, 2013 at 12:50:26PM +0100, Luigi Rizzo wrote:
On Wed, Jan 23, 2013 at 12:10:55PM +0100, Stefan Hajnoczi wrote:
On Tue, Jan 22, 2013 at 08:12:15AM +0100, Luigi Rizzo wrote:
...
+// a fast copy routine only
On Wed, Jan 23, 2013 at 8:03 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
I'm even doubtful that it's always a win on FreeBSD. You have a
threshold to fall back to bcopy() and who knows what the best value
for various CPUs is.
indeed.
With the attached program (which however might
-by: Luigi Rizzo ri...@iet.unipi.it
--
configure | 31 +
net/Makefile.objs |1 +
net/clients.h |4 +
net/net.c |3 +
net/qemu-netmap.c | 353 +
net/queue.c | 15 +++
qapi-schema.json |8 +-
7 files
luigi
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
net/hub.c | 13 +
net/hub.h |1 +
net/net.c |6 ++
diff --git a/net/hub.c b/net/hub.c
index a24c9d1..08f95d0 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -338,3 +338,16 @@ void net_hub_check_clients(void
within
the guests. I have not tried with virtio.
cheers
luigi
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
--
configure | 31 +
net/Makefile.objs |1 +
net/clients.h |4 +
net/net.c |3 +
net/qemu-netmap.c | 353
While running qemu 1.3.0 with the following network-related flags:
-net nic -net tap,ifname=tap0,script=''
I encountered the same problem (should be common to several
frontends, e.g. e100, eepro100, virtio-net, xen_nic):
in net/tap.c :: tap_send(), if qemu_send_packet_async() returns 0
small correction:
On Sun, Jan 20, 2013 at 6:50 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
While running qemu 1.3.0 with the following network-related flags:
-net nic -net tap,ifname=tap0,script=''
I encountered the same problem (should be common to several
frontends, e.g. e100
counting the packet.
What do you think, which way do you prefer ?
cheers
luigi
On Sun, Jan 20, 2013 at 6:50 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
While running qemu 1.3.0 with the following network-related flags:
-net nic -net tap,ifname=tap0,script=''
I encountered the same
On Fri, Jan 18, 2013 at 05:14:02PM +0100, Paolo Bonzini wrote:
...
This relies on the assumption that the ring (which is contiguous in the
guest's physical address space) is also contiguous in the host's virtual
address space. In principle the property could be easily verified once
the
Hi,
with a bunch of e1000 improvements we are at a point where we are
doing over 1Mpps (short frames) and 7-8Gbit/s (1500 byte frames)
between two guests, and two things that are high in the perf top
stats are phys_page_find() and related memory copies.
Both are triggered by the pci_dma_read()
On Fri, Jan 18, 2013 at 05:14:02PM +0100, Paolo Bonzini wrote:
Il 18/01/2013 17:04, Luigi Rizzo ha scritto:
Hi,
with a bunch of e1000 improvements we are at a point where we are
doing over 1Mpps (short frames) and 7-8Gbit/s (1500 byte frames)
between two guests, and two things
On Thu, Jan 17, 2013 at 2:21 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Jan 17, 2013 at 07:07:11AM +0100, Luigi Rizzo wrote:
The comment at the beginning of net/queue.c says that packets that
cannot be sent by qemu_net_queue_send() should not be enqueued
unless a callback is set
On Mon, Jan 7, 2013 at 5:49 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Sun, Jan 06, 2013 at 08:23:56PM +0100, Luigi Rizzo wrote:
Hi,
while testing the tx path in qemu without a network backend connected,
i noticed that qemu_net_queue_send() builds up an unbounded
queue, because
measure the patch implements bounded size queues
(though it should not be necessary now because each source can only have
one packet queued). When a packet is dropped because excessive
queue size the callback is not supposed to be called.
cheers
luigi
Signed-off-by: Luigi Rizzo ri...@iet.unipi.it
On Thu, Jan 10, 2013 at 01:25:48PM +0100, Stefan Hajnoczi wrote:
On Thu, Dec 27, 2012 at 11:06:58AM +0100, Luigi Rizzo wrote:
diff -urp qemu-1.3.0-orig/hw/e1000.c qemu-1.3.0/hw/e1000.c
--- qemu-1.3.0-orig/hw/e1000.c 2012-12-03 20:37:05.0 +0100
+++ qemu-1.3.0/hw/e1000.c 2012
On Mon, Jan 7, 2013 at 2:49 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Sun, Jan 06, 2013 at 08:23:56PM +0100, Luigi Rizzo wrote:
Hi,
while testing the tx path in qemu without a network backend connected,
i noticed that qemu_net_queue_send() builds up an unbounded
queue, because
Hi,
while testing the tx path in qemu without a network backend connected,
i noticed that qemu_net_queue_send() builds up an unbounded
queue, because QTAILQ* have no notion of a queue length.
As a result, memory usage of a qemu instance can grow to extremely
large values.
I wonder if it makes
are you going to distribute a 1.3.x snapshot with the updated bios that
lets FreeBSD boot ?
thanks
luigi
On Wed, Jan 2, 2013 at 5:57 PM, Anthony Liguori anth...@codemonkey.wswrote:
Gerd Hoffmann kra...@redhat.com writes:
Hi,
One more seabios update, fixing the FreeBSD build failure.
Before submitting a proper patch, I'd like to hear feedback on the
following proposed change to hw/e1000.c to properly implement
interrupt mitigation.
This is joint work with Vincenzo Maffione and Giuseppe Lettieri (in Cc),
and is a followup to a similar patch i posted in july
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
On Wed, Dec 12, 2012 at 06:47:58PM +0100, Paolo Bonzini wrote:
Il 12/12/2012 17:04, Luigi Rizzo ha scritto:
I am not sure if it has been reported already but this commit
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86
(replacing pc-bios/bios.bin
On Wed, Jul 25, 2012 at 11:53:29AM +0300, Avi Kivity wrote:
On 07/24/2012 07:58 PM, Luigi Rizzo wrote:
I noticed that the various NIC modules in qemu/kvm do not implement
interrupt mitigation, which is very beneficial as it dramatically
reduces exits from the hypervisor.
As a proof
On Wed, Jul 25, 2012 at 12:12:55PM +0200, Paolo Bonzini wrote:
Il 25/07/2012 11:56, Luigi Rizzo ha scritto:
On Wed, Jul 25, 2012 at 11:53:29AM +0300, Avi Kivity wrote:
On 07/24/2012 07:58 PM, Luigi Rizzo wrote:
I noticed that the various NIC modules in qemu/kvm do not implement
interrupt
Paolo,
a few weeks ago you posted the patch below but apparently
it did not get in after my 'tested-by' reply of June C1st4th
I'd like to confirm that your patch works perfectly for me.
Tested-by: Luigi Rizzo ri...@iet.unipi.it
cheers
luigi
On Thu, May 31, 2012 at 01:03:35PM +0200, Paolo
I noticed that the various NIC modules in qemu/kvm do not implement
interrupt mitigation, which is very beneficial as it dramatically
reduces exits from the hypervisor.
As a proof of concept i tried to implement it for the e1000 driver
(patch below), and it brings tx performance from 9 to 56Kpps
On Thu, Jul 19, 2012 at 04:43:05PM +0200, Luigi Rizzo wrote:
hi,
while playing with various qemu versions i noticed that
qemu-devel now in FreeBSD ports (1.1.0) is slow as hell when
booting FreeBSD (take for instance the netmap image at
http://info.iet.unipi.it/~luigi/netmap/20120608-netmap
text+data for the kernel.
See my followup, it was due to configure using --enable-tcg-interpreter
when using CLANG.
cheers
luigi
regards
ronnie sahlberg
On Fri, Jul 20, 2012 at 12:43 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
hi,
while playing with various qemu versions i noticed
hi,
while playing with various qemu versions i noticed that
qemu-devel now in FreeBSD ports (1.1.0) is slow as hell when
booting FreeBSD (take for instance the netmap image at
http://info.iet.unipi.it/~luigi/netmap/20120608-netmap-picobsd-head-amd64.bin
while 0.11.x and 1.1.1 and 1.0.1 seem to
We have just completed a netmap extensions that let you build a
local high speed switch called VALE which i think can be very useful.
http://info.iet.unipi.it/~luigi/vale/
VALE is a software Virtual Local Ethernet whose ports are accessible
using the netmap API. Designed to be used as the
Works me. I can now receive at 1.15 Mpps, slightly
faster than my previous patch which generated unnecessary
writes to the signalling socket.
Tested-by: Luigi Rizzo ri...@iet.unipi.it
On Thu, May 31, 2012 at 12:03 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 31/05/2012 10:23, Jan Kiszka ha
On Thu, May 31, 2012 at 9:38 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 31/05/2012 00:53, Luigi Rizzo ha scritto:
The image contains my fast packet generator pkt-gen (a stock
traffic generator such as netperf etc. is too slow to show the
problem). pkt-gen can send about 1Mpps
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
On Thu, May 31, 2012 at 11:18 AM, Stefan Hajnoczi stefa...@gmail.comwrote:
On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar
On Thu, May 31, 2012 at 03:23:12PM +0200, Jan Kiszka wrote:
On 2012-05-31 15:19, Paolo Bonzini wrote:
Il 31/05/2012 15:07, Zhi Yong Wu ha scritto:
Yeah, this case actually exists, but tcp/ip protocol stack in guest
will make sure this ordering will finally be correct.
Nevertheless it's
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below,
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below,
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below,
luigi
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
-+---
On Wed, May 30, 2012 at 10:23:11PM +0200, Luigi Rizzo wrote:
...
The problem was fixed by the following one-line addition to
hw/e1000.c :: e1000_mmio_write() , to wakeup the qemu mainloop and
check that some buffers might be available.
--- hw/e1000.c.orig 2012-02-17 20:45
On Wed, May 30, 2012 at 11:39 PM, Jan Kiszka jan.kis...@web.de wrote:
Please keep CCs.
ok
On 2012-05-30 23:23, Luigi Rizzo wrote:
On Wed, May 30, 2012 at 10:23:11PM +0200, Luigi Rizzo wrote:
...
The problem was fixed by the following one-line addition to
hw/e1000.c
On Thu, May 31, 2012 at 12:11 AM, Jan Kiszka jan.kis...@web.de wrote:
On 2012-05-30 23:55, Luigi Rizzo wrote:
you can take the freebsd image from the netmap page in my link and run it
in qemu, and then run the pkt-gen program in the image in either
send or receive mode
71 matches
Mail list logo
