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

[Zhi Yong Wu]

On Thu, May 17, 2012 at 5:51 PM, Paolo Bonzini <address@hidden> wrote:
> Il 17/05/2012 07:59, Zhi Yong Wu ha scritto:
>>> > However, then I noticed that qemu_can_send_packet is not called very much,
>>> > and I do not understand why qemu_net_queue_send and 
>>> > qemu_net_queue_send_iov
>>> > do not call qemu_can_send_packet before calling deliver/deliver_iov.
>> 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.

>
>> 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?

>
> Paolo



-- 
Regards,

Zhi Yong Wu