On Tue, Apr 7, 2015 at 6:54 PM, Alexander Graf 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
struct change would have
been of course possible, but at the cost
extra complexity in the kernel and in userspace
(to support two slightly different interfaces).
Since netmap is (so far) relatively little used I thought it
was more important to fix the API and keep it simple.
cheers
luigi
-
On Fri, Feb 14, 2014 at 2:20 AM, Vincenzo Maffione wrote:
> 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" (both tx and r
; > savevm.c| 2 +-
> > > 35 files changed, 155 insertions(+), 90 deletions(-)
> >
> > Please split this into multiple patches:
> >
> > 1. net subsystem API change that touches all files (if necessary)
> > 2. e1000 MORE support
> > 3. virtio-net MORE support
> > 4. netmap 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
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
;spin" (which indeed does use the "pause" instruction, but is not
used unless you force it with "sysctl machdep.idle=spin").
"pause" instructions are however used within spinlocks, and when
invoking the scheduler, which happens right before and after the idle lo
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 k
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
offending files that can be found with
grep '#!' scripts/*
Signed-off-by: Luigi Rizzo
---
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
--- a/scripts/acpi_extrac
On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori wrote:
> On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo 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
> 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 wrote:
...
> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione
> >> wrote:
> >> > This patch adds support for a network backend based on netmap.
On Mon, Nov 4, 2013 at 9:41 AM, Anthony Liguori wrote:
> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione
> 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 build extremely fast traffic generator
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
xisting
style issue he can do it separately, or make a comment in the
commit log if he has no time (and by the same reasoning, the original
submitter may be short of time).
cheers
luigi
Many projects i have been involved with have this
>
> drew
>
> >
> > Sincerely,
> >
>
On Mon, Feb 18, 2013 at 1:50 AM, Stefan Hajnoczi 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 (w
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
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: w
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
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
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)
> >
On Fri, Feb 8, 2013 at 2:02 AM, Stefan Hajnoczi 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 im
http://info.iet.unipi.it/~luigi/research.html#qemu
cheers
luigi
Signed-off-by: Luigi Rizzo
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 *autoneg_timer
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
diff --git a/net/queue.c b/net/queue.c
index 6eaf5b6..859d02a
luigi
Signed-off-by: Luigi Rizzo
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;
+NetHubPort *sourc
(hub)hub0port1 <--[queue A]-- tap.0
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
diff --git a/net/hub.c b/net/hub.c
index a24c9d1..df32074 100644
--- a/net/hub.c
+++
On Thu, Jan 24, 2013 at 11:24 PM, Stefan Hajnoczi wrote:
> On Thu, Jan 24, 2013 at 6:35 PM, Luigi Rizzo wrote:
>
> >> >
> >> > never mind, pilot error. in my test program i had swapped the
> >> > arguments to __builtin_memcpy(). With the correct
On Fri, Jan 25, 2013 at 9:23 AM, Michael Tokarev 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
3442119
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 wrote:
> >
> > > > I'm even doubtful that it's always a win on FreeBSD. You hav
On Wed, Jan 23, 2013 at 8:03 AM, Luigi Rizzo 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 attac
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:
...
>
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 implemen
On Tue, Jan 22, 2013 at 2:50 PM, Anthony Liguori wrote:
> 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 it
> or respo
Mpps using netmap within
the guests. I have not tried with virtio.
cheers
luigi
Signed-off-by: Luigi Rizzo
--
configure | 31 +
net/Makefile.objs |1 +
net/clients.h |4 +
net/net.c |3 +
net/qemu-netma
cheers
luigi
Signed-off-by: Luigi Rizzo
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)
}
}
}
+
ned-off-by: Luigi Rizzo
--
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 ch
mpossible, but it requires reference
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 wrote:
> While running qemu 1.3.0 with the following network-related flags:
>
> -net nic -net tap,ifname=tap0,script=&#
small correction:
On Sun, Jan 20, 2013 at 6:50 PM, Luigi Rizzo 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,
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
(
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
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() a
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
> >
On Thu, Jan 17, 2013 at 2:21 AM, Stefan Hajnoczi 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
> > unl
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
--- ../orig/net
On Mon, Jan 7, 2013 at 5:49 AM, Stefan Hajnoczi 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
> >
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
> > +++
On Mon, Jan 7, 2013 at 2:49 PM, Stefan Hajnoczi 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
> >
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 sen
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 wrote:
> Gerd Hoffmann writes:
>
> > Hi,
> >
> > One more seabios update, fixing the FreeBSD build failure.
> >
> > please pull,
> > Gerd
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
https://lists.gnu.o
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
&
00
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
Reverting the bios fixes things.
I wonder if it isn't the case of reverting this change ?
cheers
luigi
--
-+-----
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 module
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 hy
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 o
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
cheers
luigi
On Thu, May 31, 2012 at 01:03:35PM +0200, Paolo Bonzini
d
to load 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 wrote:
> > hi,
> > while playing with various q
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/~lui
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 wo
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
On Thu, May 31, 2012 at 12:03 PM, Paolo Bonzini wrote:
> Il 31/05/2012 10:23, Jan Kiszka ha scritto:
> >> > @
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.
> >
> > Never
On Thu, May 31, 2012 at 11:18 AM, Stefan Hajnoczi wrote:
> On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo wrote:
> > Hi,
> > while investigating rx performance for emulated network devices
> > (i am looking at the userspace version, relying on net=tap
> > or similar app
s able to receive again.
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
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
On Thu, May 31, 2012 at 9:38 AM, Paolo Bonzini 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-g
On Thu, May 31, 2012 at 12:11 AM, Jan Kiszka 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. But thi
On Wed, May 30, 2012 at 11:39 PM, Jan Kiszka 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 followin
> 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.
> >
> > -
nism.
cheers
luigi
-+-------
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
-+---
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, ju
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, ju
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, ju
71 matches
Mail list logo
