Re: Receiving delayed packets from RTL8139 card in KVM

[Avi Kivity <avi@redhat.com>]

  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