search for: handle_rx

...? cpu_relax(); >>>>> +???? } >>>>> + >>>>> +???? preempt_enable(); >>>>> + >>>>> +???? if (!rx) >>>>> +???????????? vhost_net_enable_vq(net, vq); >>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>> called soon. >>> If we disable rx virtqueue in handle_tx and don't send packets from >>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>> so the network is broken. >> Not sure I understand here. I mean is we s...

...? cpu_relax(); >>>>> +???? } >>>>> + >>>>> +???? preempt_enable(); >>>>> + >>>>> +???? if (!rx) >>>>> +???????????? vhost_net_enable_vq(net, vq); >>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>> called soon. >>> If we disable rx virtqueue in handle_tx and don't send packets from >>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>> so the network is broken. >> Not sure I understand here. I mean is we s...

...at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcoun...

...at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcoun...

...>>>>>> + >>>>>>> + preempt_enable(); >>>>>>> + >>>>>>> + if (!rx) >>>>>>> + vhost_net_enable_vq(net, vq); >>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>> called soon. >>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>> so the network is broken. >>>> No...

...>>>>>> + >>>>>>> + preempt_enable(); >>>>>>> + >>>>>>> + if (!rx) >>>>>>> + vhost_net_enable_vq(net, vq); >>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>> called soon. >>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>> so the network is broken. >>>> No...

On 2018/08/03 12:07, Jason Wang wrote: > On 2018?08?02? 17:23, Jason Wang wrote: >>>>>>> >>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>> called soon. >>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>> so the network is broken. >>>> No...

...eempt_enable(); >>>>>>>>>>> + >>>>>>>>>>> + if (!rx) >>>>>>>>>>> + vhost_net_enable_vq(net, vq); >>>>>>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>>>>>> called soon. >>>>>>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>>>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>&g...

...ao Zhang wrote: >>> + >>> + cpu_relax(); >>> + } >>> + >>> + preempt_enable(); >>> + >>> + if (!rx) >>> + vhost_net_enable_vq(net, vq); >> No need to enable rx virtqueue, if we are sure handle_rx() will be >> called soon. > If we disable rx virtqueue in handle_tx and don't send packets from > guest anymore(handle_tx is not called), so we can wake up for sock rx. > so the network is broken. Not sure I understand here. I mean is we schedule work for handle_rx(), there'...

...ao Zhang wrote: >>> + >>> + cpu_relax(); >>> + } >>> + >>> + preempt_enable(); >>> + >>> + if (!rx) >>> + vhost_net_enable_vq(net, vq); >> No need to enable rx virtqueue, if we are sure handle_rx() will be >> called soon. > If we disable rx virtqueue in handle_tx and don't send packets from > guest anymore(handle_tx is not called), so we can wake up for sock rx. > so the network is broken. Not sure I understand here. I mean is we schedule work for handle_rx(), there'...

...gt;>>>>> + preempt_enable(); >>>>>>>>> + >>>>>>>>> + if (!rx) >>>>>>>>> + vhost_net_enable_vq(net, vq); >>>>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>>>> called soon. >>>>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>>>> so the networ...

...gt;>>>>> + preempt_enable(); >>>>>>>>> + >>>>>>>>> + if (!rx) >>>>>>>>> + vhost_net_enable_vq(net, vq); >>>>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>>>> called soon. >>>>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>>>> so the networ...

...gt;>>>>> + preempt_enable(); >>>>>>>>> + >>>>>>>>> + if (!rx) >>>>>>>>> + vhost_net_enable_vq(net, vq); >>>>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>>>> called soon. >>>>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>>>> so the networ...

...gt;>>>>> + preempt_enable(); >>>>>>>>> + >>>>>>>>> + if (!rx) >>>>>>>>> + vhost_net_enable_vq(net, vq); >>>>>>>> No need to enable rx virtqueue, if we are sure handle_rx() will be >>>>>>>> called soon. >>>>>>> If we disable rx virtqueue in handle_tx and don't send packets from >>>>>>> guest anymore(handle_tx is not called), so we can wake up for sock rx. >>>>>>> so the networ...

...at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcoun...

...at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcoun...

...at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcoun...

...throughput regression with commit > > c67df11f(vhost_net: try batch dequing from skb array) as discussed > > in the following thread: > > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > > > Eventually we figured out that it was a skb leak in handle_rx() > > when sending packets to the VM. This usually happens when a guest > > can not drain out vq as fast as vhost fills in, afterwards it sets > > off the traffic jam and leaks skb(s) which occurs as no headcount > > to send on the vq from vhost side. > > > > Th...

...throughput regression with commit > > c67df11f(vhost_net: try batch dequing from skb array) as discussed > > in the following thread: > > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > > > Eventually we figured out that it was a skb leak in handle_rx() > > when sending packets to the VM. This usually happens when a guest > > can not drain out vq as fast as vhost fills in, afterwards it sets > > off the traffic jam and leaks skb(s) which occurs as no headcount > > to send on the vq from vhost side. > > > > Th...

...ew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured out that it was a skb leak in handle_rx() > when sending packets to the VM. This usually happens when a guest > can not drain out vq as fast as vhost fills in, afterwards it sets > off the traffic jam and leaks skb(s) which occurs as no headcount > to send on the vq from vhost side. > > This can be avoided by making sur...