Il 17/05/2012 12:05, Zhi Yong Wu ha scritto: > On Thu, May 17, 2012 at 5:51 PM, Paolo Bonzini <pbonz...@redhat.com> 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
