similar to: domU has a better networking than dom0

box. I'll send an updated KVM tools patch in a bit as well. Before: # netperf -H 192.168.33.4,ipv4 -t TCP_RR MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes

box. I'll send an updated KVM tools patch in a bit as well. Before: # netperf -H 192.168.33.4,ipv4 -t TCP_RR MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes

On 2020/7/1 ??9:04, Eugenio Perez Martin wrote: > On Wed, Jul 1, 2020 at 2:40 PM Jason Wang <jasowang at redhat.com> wrote: >> >> On 2020/7/1 ??6:43, Eugenio Perez Martin wrote: >>> On Tue, Jun 23, 2020 at 6:15 PM Eugenio Perez Martin >>> <eperezma at redhat.com> wrote: >>>> On Mon, Jun 22, 2020 at 6:29 PM Michael S. Tsirkin <mst at

On 2020/7/1 ??6:43, Eugenio Perez Martin wrote: > On Tue, Jun 23, 2020 at 6:15 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: >> On Mon, Jun 22, 2020 at 6:29 PM Michael S. Tsirkin <mst at redhat.com> wrote: >>> On Mon, Jun 22, 2020 at 06:11:21PM +0200, Eugenio Perez Martin wrote: >>>> On Mon, Jun 22, 2020 at 5:55 PM Michael S. Tsirkin <mst

On Wed, Jul 01, 2020 at 12:43:09PM +0200, Eugenio Perez Martin wrote: > On Tue, Jun 23, 2020 at 6:15 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: > > > > On Mon, Jun 22, 2020 at 6:29 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Mon, Jun 22, 2020 at 06:11:21PM +0200, Eugenio Perez Martin wrote: > > > > On

On Thu, Jul 09, 2020 at 06:46:13PM +0200, Eugenio Perez Martin wrote: > On Wed, Jul 1, 2020 at 4:10 PM Jason Wang <jasowang at redhat.com> wrote: > > > > > > On 2020/7/1 ??9:04, Eugenio Perez Martin wrote: > > > On Wed, Jul 1, 2020 at 2:40 PM Jason Wang <jasowang at redhat.com> wrote: > > >> > > >> On 2020/7/1 ??6:43, Eugenio Perez

On Fri, Apr 06, 2018 at 08:22:37AM +0000, haibinzhang(???) wrote: > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > polling udp packets with small length(e.g. 1byte udp payload), because setting > VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length. > > Ping-Latencies shown below were tested between two Virtual Machines

On Mon, Apr 09, 2018 at 04:09:20AM +0000, haibinzhang(???) wrote: > > > On Fri, Apr 06, 2018 at 08:22:37AM +0000, haibinzhang(???) wrote: > > > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > > > polling udp packets with small length(e.g. 1byte udp payload), because setting > > > VHOST_NET_WEIGHT takes into account only

On Tue, Apr 03, 2018 at 08:08:26AM +0000, haibinzhang(???) wrote: > handle_tx will delay rx for a long time when tx busy polling udp packets > with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > takes into account only sent-bytes but no single packet length. > > Tests were done between two Virtual Machines using netperf(UDP_STREAM, len=1), > then

On 2020/6/20 ??2:07, Eugenio Perez Martin wrote: > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: >> On Thu, Jun 11, 2020 at 5:22 PM Konrad Rzeszutek Wilk >> <konrad.wilk at oracle.com> wrote: >>> On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote: >>>> As testing shows no performance change,

On Fri, Jun 19, 2020 at 08:07:57PM +0200, Eugenio Perez Martin wrote: > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: > > > > On Thu, Jun 11, 2020 at 5:22 PM Konrad Rzeszutek Wilk > > <konrad.wilk at oracle.com> wrote: > > > > > > On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote: >

On Tue, Apr 03, 2018 at 12:29:47PM +0000, haibinzhang(???) wrote: > > >On Tue, Apr 03, 2018 at 08:08:26AM +0000, haibinzhang wrote: > >> handle_tx will delay rx for a long time when tx busy polling udp packets > >> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > >> takes into account only sent-bytes but no single packet length.

On Mon, Jun 22, 2020 at 06:11:21PM +0200, Eugenio Perez Martin wrote: > On Mon, Jun 22, 2020 at 5:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, Jun 19, 2020 at 08:07:57PM +0200, Eugenio Perez Martin wrote: > > > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > > > <eperezma at redhat.com> wrote: > > > > > >

The main purpose of this patch is adding a way of checking per-queue stats. It's useful to debug performance problems on multiqueue environment. $ ethtool -S ens10 NIC statistics: rx_queue_0_packets: 2090408 rx_queue_0_bytes: 3164825094 rx_queue_1_packets: 2082531 rx_queue_1_bytes: 3152932314 tx_queue_0_packets: 2770841 tx_queue_0_bytes: 4194955474

From: Willem de Bruijn <willemb at google.com> Add napi for virtio-net transmit completion processing. Changes: v2 -> v3: - convert __netif_tx_trylock to __netif_tx_lock on tx napi poll ensure that the handler always cleans, to avoid deadlock - unconditionally clean in start_xmit avoid adding an unnecessary "if (use_napi)" branch - remove

From: Willem de Bruijn <willemb at google.com> Add napi for virtio-net transmit completion processing. Changes: v2 -> v3: - convert __netif_tx_trylock to __netif_tx_lock on tx napi poll ensure that the handler always cleans, to avoid deadlock - unconditionally clean in start_xmit avoid adding an unnecessary "if (use_napi)" branch - remove

On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: > Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able > to be rescheduled within napi_complete_done() even in non-busypoll case, > but virtnet_poll() always enabled interrupts before complete, and when > napi was rescheduled within napi_complete_done() it did not disable > interrupts. >

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

On 2017?12?07? 13:09, Michael S. Tsirkin wrote: > On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: >> Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able >> to be rescheduled within napi_complete_done() even in non-busypoll case, >> but virtnet_poll() always enabled interrupts before complete, and when >> napi was rescheduled