qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax
Date: Thu, 17 May 2012 15:29:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Il 17/05/2012 12:05, Zhi Yong Wu ha scritto:
> On Thu, May 17, 2012 at 5:51 PM, Paolo Bonzini <address@hidden> wrote:
>>> This case has existed in current upstream code, not only vlan-hub
>>> code. Currently can_send function has been called by backend send
>>> function before deliver/deliver_iov, If we put can_send in queue send
>>> function, your idea will have a big challenge for slirp packet queue.
>>
>> Exactly why?  For SLIRP's receive path, SLIRP doesn't implement
>> can_receive at all so it will never block.  For the send path, when flow
>> control kicks qemu_net_queue_append will copy the packet so it is not a
>> problem for SLIRP's stack-allocated packets.
>
> You know that qemu_send_packet is void type, and has return value, if
> can_send fails, if_encap will not currently get expected return value,
> so this will cause that we have to modify the definition of
> qemu_send_packet to make it return one valid value. a lot of functions
> have called it, so i would not like to modify its definition.

If qemu_can_send_packet returns false of course I would not drop the
packet.  I would append it to the queue (qemu_net_queue_append) for
later processing.

>>> We can implement your idea below later, not in this patchset. What do
>>> you think?
>>
>> Note that my idea above was only means to an end.  If you can remove the
>> TODOs in a convincing manner, that would be fine.
> You mean that we need adopt another handling way? or directly TODO comments?

You need to address the TODOs.  I proposed a way.  It may actually not
be correct, and there may of course be others.  But the TODOs are there,
and have to be solved.

Paolo



reply via email to

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