qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Proposed patch: huge RX speedup for hw/e1000.c


From: Jan Kiszka
Subject: Re: [Qemu-devel] Proposed patch: huge RX speedup for hw/e1000.c
Date: Thu, 31 May 2012 10:41:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-05-31 10:32, Luigi Rizzo wrote:
> On Thu, May 31, 2012 at 10:23 AM, Jan Kiszka <address@hidden> wrote:
> 
>> On 2012-05-31 09:38, Paolo Bonzini wrote
>>
> ...
> 
>>
>> This still looks like the wrong tool: Packets that can't be delivered
>> are queued. So we need to flush the queue and clear the blocked delivery
>> there. qemu_flush_queued_packets appears more appropriate for this.
>>
>> Conceptually, the backend should be responsible for kicking the iothread
>> as needed.
>>
>>
> as i understand the code, the backend _is_ the iothread, and it is
> sleeping when the frontend becomes able to receive again.

The backend is a subsystem that can run in the context of the vcpu or
the iothread. The question is in which context which job shall run.
That's something the backend should decide, not the NIC (who should be
agnostic of the I/O architecture - we may have different ones in the
future). Possibly it does make sense to run the flush over a different
context than the vcpu, but let's keep this decision out of the NICs.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]