On 2012-05-31 15:45, Zhi Yong Wu wrote:
> On Thu, May 31, 2012 at 5:18 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
>> On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo <ri...@iet.unipi.it> 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
> If qemu_net_queue_send() are re-entranced, what issue or badness will
> it introduce?
> I haven't found what issue will take place when queue_flush() is moved
> before queue_deliver().
>
Delayed packets that are hold back during delivering==1. Having a flush
before and after may be fine - if we really need it before.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
