All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Karthik Vadambacheri Manian <karthikvm.uc@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: Receiving delayed packets from RTL8139 card in KVM
Date: Sun, 22 Aug 2010 13:14:34 +0300	[thread overview]
Message-ID: <4C70F88A.4070200@redhat.com> (raw)
In-Reply-To: <AANLkTi=vmCg8o51+QCDALL_Yz5Z-XNg7j1iQ5CEAtcEu@mail.gmail.com>

  On 08/20/2010 04:01 AM, Karthik Vadambacheri Manian wrote:
> Hi All,
>
> I am running a light weight kernel named kitten in QEMU-KVM which uses
> LWIP (Light Weight TCP/IP) stack for networking. I am trying to fine
> tune this LWIP but I am now facing an issue regarding delayed packet
> reception. Basically I wrote a small pingpong program where master
> sends a data to a slave and slave returns it back. But I see some
> retransmissions due to missing acknowledgement. When I debugged
> further I came to know the following:
>
> 1) Master sends some data to Slave
> 2) Slave receives it and sends an acknowledgement to Master. Slave
> then returns the same data to Master
> 3) Master receives both acknowledgement and the data
>
> The problem occurs in the 3 step. The master receives a single
> interrupt for both the acknowledgement packet and data packet. So the
> driver tries to read and reads the acknowledgement packet first and
> then checks again whether there is more data in the buffer and it
> reads the data packet. But sometimes the data packet is available in
> the buffer after 90-100 microseconds after acknowledgement packet,
> hence the driver thinks there is no more packet to receive. So the
> receive is failed. This causes the slave to resend the packet which
> leads to great performance loss. And from the debug messages it is
> sure that there is no delay from the slave side in sending the data
> packet.
>
> When I run the same program in QEMU everything is running perfectly. I
> think it is because the emulation itself causes a long delay within
> which the packet arrives at the buffer and hence the scenario is not
> reproduced. Hence I would like to know whether KVM has issues with the
> RTL8139 card? and how to proceed further.
>

There may be a missing wakeup in the networking path.  You can try 
adding printf()s in RTL8139's receive function, and in 
kvm_set_irq_level() to see if there's a problem in interrupt flow.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-08-22 10:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  1:01 Receiving delayed packets from RTL8139 card in KVM Karthik Vadambacheri Manian
2010-08-22 10:14 ` Avi Kivity [this message]
2010-08-26  2:10   ` Karthik Vadambacheri Manian
2010-08-26  8:14     ` Avi Kivity
2010-08-27 21:47       ` Karthik Vadambacheri Manian
2010-08-29  8:18         ` Avi Kivity

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=4C70F88A.4070200@redhat.com \
    --to=avi@redhat.com \
    --cc=karthikvm.uc@gmail.com \
    --cc=kvm@vger.kernel.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.