[PATCH net-next] virtio_net: add gro capability

[PATCH net-next] virtio_net: add gro capability

[Eric Dumazet]

From: Eric Dumazet <edumazet@google.com>

Straightforward patch to add GRO processing to virtio_net.

napi_complete_done() usage allows more aggressive aggregation,
opted-in by setting /sys/class/net/xxx/gro_flush_timeout

Tested:

Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec,
Rick Jones reported following results.

One VM of each on a pair of OpenStack compute nodes with E5-2650Lv3 CPUs
and Intel 82599ES-based NICs. So, two "before" and two "after" VMs.
The OpenStack compute nodes were running OpenStack Kilo, with VxLAN
encapsulation being used through OVS so no GRO coming-up the host
stack.  The compute nodes themselves were running a 3.14-based kernel.

Single-stream netperf, CPU utilizations and thus service demands are
based on intra-guest reported CPU.

Throughput Mbit/s, bigger is better                     
        Min     Median  Average Max
4.2.0-rc3+      1364    1686    1678    1938
4.2.0-rc3+flush1k       1824    2269    2275    2647

Send Service Demand, smaller is better                  
        Min     Median  Average Max
4.2.0-rc3+      0.236   0.558   0.524   0.802
4.2.0-rc3+flush1k       0.176   0.503   0.471   0.738

Receive Service Demand, smaller is better.      
        Min     Median  Average Max
4.2.0-rc3+      1.906   2.188   2.191   2.531
4.2.0-rc3+flush1k       0.448   0.529   0.533   0.692


Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Rick Jones <rick.jones2@hp.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
---
 drivers/net/virtio_net.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7fbca37a1adf..66f08f622dc6 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -518,7 +518,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
 
 	skb_mark_napi_id(skb, &rq->napi);
 
-	netif_receive_skb(skb);
+	napi_gro_receive(&rq->napi, skb);
 	return;
 
 frame_err:
@@ -756,7 +756,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
 	/* Out of packets? */
 	if (received < budget) {
 		r = virtqueue_enable_cb_prepare(rq->vq);
-		napi_complete(napi);
+		napi_complete_done(napi, received);
 		if (unlikely(virtqueue_poll(rq->vq, r)) &&
 		    napi_schedule_prep(napi)) {
 			virtqueue_disable_cb(rq->vq);

Re: [PATCH net-next] virtio_net: add gro capability

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 31 Jul 2015 18:25:17 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> Straightforward patch to add GRO processing to virtio_net.
> 
 ...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Rick Jones <rick.jones2@hp.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>

Michael, please review :-)

Re: [PATCH net-next] virtio_net: add gro capability

[Michael S. Tsirkin]

On Fri, Jul 31, 2015 at 04:57:32PM -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 31 Jul 2015 18:25:17 +0200
> 
> > From: Eric Dumazet <edumazet@google.com>
> > 
> > Straightforward patch to add GRO processing to virtio_net.
> > 
>  ...
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Tested-by: Rick Jones <rick.jones2@hp.com>
> > Cc: "Michael S. Tsirkin" <mst@redhat.com>
> 
> Michael, please review :-)

Will do shortly :)

Re: [PATCH net-next] virtio_net: add gro capability

[Michael S. Tsirkin]

On Fri, Jul 31, 2015 at 06:25:17PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> Straightforward patch to add GRO processing to virtio_net.
> 
> napi_complete_done() usage allows more aggressive aggregation,
> opted-in by setting /sys/class/net/xxx/gro_flush_timeout
> 
> Tested:
> 
> Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec,
> Rick Jones reported following results.
> 
> One VM of each on a pair of OpenStack compute nodes with E5-2650Lv3 CPUs
> and Intel 82599ES-based NICs. So, two "before" and two "after" VMs.
> The OpenStack compute nodes were running OpenStack Kilo, with VxLAN
> encapsulation being used through OVS so no GRO coming-up the host
> stack.  The compute nodes themselves were running a 3.14-based kernel.
> 
> Single-stream netperf, CPU utilizations and thus service demands are
> based on intra-guest reported CPU.
> 
> Throughput Mbit/s, bigger is better                     
>         Min     Median  Average Max
> 4.2.0-rc3+      1364    1686    1678    1938
> 4.2.0-rc3+flush1k       1824    2269    2275    2647
> 
> Send Service Demand, smaller is better                  
>         Min     Median  Average Max
> 4.2.0-rc3+      0.236   0.558   0.524   0.802
> 4.2.0-rc3+flush1k       0.176   0.503   0.471   0.738
> 
> Receive Service Demand, smaller is better.      
>         Min     Median  Average Max
> 4.2.0-rc3+      1.906   2.188   2.191   2.531
> 4.2.0-rc3+flush1k       0.448   0.529   0.533   0.692
> 
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Rick Jones <rick.jones2@hp.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>

Ideally this needs to also be tested on non-vxlan configs with gro in
host, to make sure this doesn't cause regressions.

But I don't see why it should: GRO overhead is pretty small if packets
don't need to be combined.

Acked-by: Michael S. Tsirkin <mst@redhat.com>


> ---
>  drivers/net/virtio_net.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7fbca37a1adf..66f08f622dc6 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -518,7 +518,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
>  
>  	skb_mark_napi_id(skb, &rq->napi);
>  
> -	netif_receive_skb(skb);
> +	napi_gro_receive(&rq->napi, skb);
>  	return;
>  
>  frame_err:
> @@ -756,7 +756,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
>  	/* Out of packets? */
>  	if (received < budget) {
>  		r = virtqueue_enable_cb_prepare(rq->vq);
> -		napi_complete(napi);
> +		napi_complete_done(napi, received);
>  		if (unlikely(virtqueue_poll(rq->vq, r)) &&
>  		    napi_schedule_prep(napi)) {
>  			virtqueue_disable_cb(rq->vq);
> 

Re: [PATCH net-next] virtio_net: add gro capability

[Rick Jones]

On 08/03/2015 06:37 AM, Michael S. Tsirkin wrote:
> Ideally this needs to also be tested on non-vxlan configs with gro in
> host, to make sure this doesn't cause regressions.

Measured with the same instances on the same hardware and software, 
taking a path through the stack (public rather than private IPs, with 
Distributed Virtual Router (DVR) enabled) which gives them GRO:

Throughput				
	Min	Median	Average	Max
4.2.0-rc3+_hostGRO	6713	8351	8232	9102
4.2.0-rc3+flush1k_hostGRO	6539	8267	8206	8982

As singletons, Mins and Maxes probably have rather high variability, I'd 
focus on the Median and Average and those are within 1%.

Send Service Demand				
	Min	Median	Average	Max
4.2.0-rc3+_hostGRO	0.332	0.496	0.490	0.651
4.2.0-rc3+flush1k_hostGRO	0.328	0.493	0.488	0.678

Receive Service Demand				
	Min	Median	Average	Max
4.2.0-rc3+_hostGRO	0.386	0.469	0.485	0.677
4.2.0-rc3+flush1k_hostGRO	0.369	0.466	0.477	0.665

happy benchmarking,

rick

Re: [PATCH net-next] virtio_net: add gro capability

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 31 Jul 2015 18:25:17 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> Straightforward patch to add GRO processing to virtio_net.
> 
> napi_complete_done() usage allows more aggressive aggregation,
> opted-in by setting /sys/class/net/xxx/gro_flush_timeout
> 
> Tested:
> 
> Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec,
> Rick Jones reported following results.
> 
> One VM of each on a pair of OpenStack compute nodes with E5-2650Lv3 CPUs
> and Intel 82599ES-based NICs. So, two "before" and two "after" VMs.
> The OpenStack compute nodes were running OpenStack Kilo, with VxLAN
> encapsulation being used through OVS so no GRO coming-up the host
> stack.  The compute nodes themselves were running a 3.14-based kernel.
> 
> Single-stream netperf, CPU utilizations and thus service demands are
> based on intra-guest reported CPU.
 ...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Rick Jones <rick.jones2@hp.com>

Applied.