qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?


From: Jan Kiszka
Subject: Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
Date: Thu, 31 May 2012 12:47:42 +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 11:18, Stefan Hajnoczi wrote:
> On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo <address@hidden> wrote:
>> 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, just for reference.
>> My impression is that the call to qemu_net_queue_flush()
>> is misplaced, and it should be before qemu_net_queue_deliver()
>> otherwise the current packet is pushed out before anything
>> was already in the queue.
>>
>> Does it make sense ?
>>
>> cheers
>> luigi
>>
>>    ssize_t qemu_net_queue_send(NetQueue *queue,
>>                                VLANClientState *sender,
>>                                unsigned flags,
>>                                const uint8_t *data,
>>                                size_t size,
>>                                NetPacketSent *sent_cb)
>>    {
>>        ssize_t ret;
>>
>>        if (queue->delivering) {
>>            return qemu_net_queue_append(queue, sender, flags, data, size, 
>> NULL);
>>        }
>>
>>        ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
>>        if (ret == 0) {
>>            qemu_net_queue_append(queue, sender, flags, data, size, sent_cb);
>>            return 0;
>>        }
>>
>>        qemu_net_queue_flush(queue);
> 
> This of the case where delivering a packet causes additional
> (re-entrant) qemu_net_queue_send() calls to this queue.  We'll be in
> ->delivering state and queue those packets.  After we've finished
> delivering the initial packet we flush the queue.
> 
> This is a weird case but this is how I read the intention of the code.
> 
> Jan: maybe slirp can do this re-entrant qemu_net_queue_send()?

Yep, when working with a VLAN queue (*): transmission of the NIC will
directly be processed by slirp in the sender's context and can make it
send a reply, also in this context.

Jan

(*) Makes me wonder if this was considered for the hub patches.

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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