Re: Receiving delayed packets from RTL8139 card in KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 On 08/26/2010 05:10 AM, Karthik Vadambacheri Manian wrote:
Hi Avi,

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.
Thanks for your insights. I debugged the RTL8139's receive function
rtl8139_do_receive() and the functions rtl8139_update_irq()
(responsible for initiating the rtl8139 interrupts) and
kvm_set_irq_level(). I came to know that the packets were not delayed
as opposed to previous assumption. Also the interrupts were promptly
provided by the rtl8139 using rtl8139_update_irq(). Also it seems
kvm_set_irq_level() injects the interrupts to the guest properly.

But inside the guest(kitten LWK) I see the number of interrupts to be
less than what is injected from KVM. This may be due to the interrupts
being coalesced in KVM before injection or the guest somehow misses
some interrupts. I feel the coalescing of the interrupts may cause the
problem in my application. For eg. Two packets needs to be received,
hence instead of injecting two interrupts only one coalesced interrupt
is injected to the guest. The RTL8139 driver in guest on receiving the
coalesced interrupt reads the first packet(which is present in buffer)
but when it tries to read the next packet immediately, the packet has
not yet arrived to the guest's RTL8139's buffer hence it assumes no
more data and returns. The second packet here is not received leading
to retransmission. But in this scenario if a second interrupt occured
then the driver would have once again checked the buffer to find the
data available thereby avoiding retransmission.

Please let me know what is the minimum time between interrupts to be
considered for coalescing. Is it possible to reduce this time further
as it will be useful in my case. Please let me know your comments on
this issue.

Interrupts are not coalesced based on time; the interrupt is level-triggered, which means it is raised as long as it is not masked by the guest.

The guest ISR should look something like this:

ISR:
   mask interrupt
   process all packets
   unmask interrupts
   if packets have become available:
     goto ISR


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux