linux-toradex.git/drivers/net/hyperv/hyperv_net.h, branch v3.18-rc5 Linux kernel for Apalis and Colibri modules hyperv: Increase the buffer length for netvsc_channel_cb() 2014-08-22T19:23:09+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-08-15T19:18:19+00:00 f90251c8a6d06ed8b072a2a0f13c4b8a6d0cb222 When the buffer is too small for a packet from VMBus, a bigger buffer will be allocated in netvsc_channel_cb() and retry reading the packet from VMBus. Increasing this buffer size will reduce the retry overhead. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
When the buffer is too small for a packet from VMBus, a bigger buffer will be
allocated in netvsc_channel_cb() and retry reading the packet from VMBus.
Increasing this buffer size will reduce the retry overhead.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Adjust the size of sendbuf region to support ws2008r2 2014-08-06T20:52:07+00:00 KY Srinivasan kys@microsoft.com 2014-08-06T18:11:00+00:00 be136ed30a4345e42ad846c1b9d925932dab303b WS2008R2 is a supported platform and it turns out that the maximum sendbuf size that ws2008R2 can support is only 15MB. Make the necessary adjustment. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
WS2008R2 is a supported platform and it turns out that the maximum sendbuf
size that ws2008R2 can support is only 15MB. Make the necessary
adjustment.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Drivers: net-next: hyperv: Increase the size of the sendbuf region 2014-08-04T22:07:14+00:00 KY Srinivasan kys@microsoft.com 2014-08-02T17:42:02+00:00 06b47aac4924180d63aad50727a11230d876c348 Intel did some benchmarking on our network throughput when Linux on Hyper-V is as used as a gateway. This fix gave us almost a 1 Gbps additional throughput on about 5Gbps base throughput we hadi, prior to increasing the sendbuf size. The sendbuf mechanism is a copy based transport that we have which is clearly more optimal than the copy-free page flipping mechanism (for small packets). In the forwarding scenario, we deal only with MTU sized packets, and increasing the size of the senbuf area gave us the additional performance. For what it is worth, Windows guests on Hyper-V, I am told use similar sendbuf size as well. The exact value of sendbuf I think is less important than the fact that it needs to be larger than what Linux can allocate as physically contiguous memory. Thus the change over to allocating via vmalloc(). We currently allocate 16MB receive buffer and we use vmalloc there for allocation. Also the low level channel code has already been modified to deal with physically dis-contiguous memory in the ringbuffer setup. Based on experimentation Intel did, they say there was some improvement in throughput as the sendbuf size was increased up to 16MB and there was no effect on throughput beyond 16MB. Thus I have chosen 16MB here. Increasing the sendbuf value makes a material difference in small packet handling In this version of the patch, based on David's feedback, I have added additional details in the commit log. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Intel did some benchmarking on our network throughput when Linux on Hyper-V
is as used as a gateway. This fix gave us almost a 1 Gbps additional throughput
on about 5Gbps base throughput we hadi, prior to increasing the sendbuf size.
The sendbuf mechanism is a copy based transport that we have which is clearly
more optimal than the copy-free page flipping mechanism (for small packets).
In the forwarding scenario, we deal only with MTU sized packets,
and increasing the size of the senbuf area gave us the additional performance.
For what it is worth, Windows guests on Hyper-V, I am told use similar sendbuf
size as well.

The exact value of sendbuf I think is less important than the fact that it needs
to be larger than what Linux can allocate as physically contiguous memory.
Thus the change over to allocating via vmalloc().

We currently allocate 16MB receive buffer and we use vmalloc there for allocation.
Also the low level channel code has already been modified to deal with physically
dis-contiguous memory in the ringbuffer setup.

Based on experimentation Intel did, they say there was some improvement in throughput
as the sendbuf size was increased up to 16MB and there was no effect on throughput
beyond 16MB. Thus I have chosen 16MB here.

Increasing the sendbuf value makes a material difference in small packet handling

In this version of the patch, based on David's feedback, I have added
additional details in the commit log.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event 2014-06-20T04:17:37+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-06-20T01:34:36+00:00 3a494e710367c0a233d86bcde9853781859fc008 The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host sleep or hibernation. We refresh network at this time. MS-TFS: 135162 Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host
sleep or hibernation. We refresh network at this time.
MS-TFS: 135162

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Add hash value into RNDIS Per-packet info 2014-05-23T18:49:00+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-05-21T19:55:39+00:00 307f099520b66504cf6c5638f3f404c48b9fb45b It passes the hash value as the RNDIS Per-packet info to the Hyper-V host, so that the send completion notices can be spread across multiple channels. MS-TFS: 140273 Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
It passes the hash value as the RNDIS Per-packet info to the Hyper-V host,
so that the send completion notices can be spread across multiple channels.
MS-TFS: 140273

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Enable sendbuf mechanism on the send path 2014-04-30T17:48:46+00:00 KY Srinivasan kys@microsoft.com 2014-04-30T17:14:31+00:00 c25aaf814a63f9d9c4e45416f13d70ef0aa0be2e We send packets using a copy-free mechanism (this is the Guest to Host transport via VMBUS). While this is obviously optimal for large packets, it may not be optimal for small packets. Hyper-V host supports a second mechanism for sending packets that is "copy based". We implement that mechanism in this patch. In this version of the patch I have addressed a comment from David Miller. With this patch (and all of the other offload and VRSS patches), we are now able to almost saturate a 10G interface between Linux VMs on Hyper-V on different hosts - close to 9 Gbps as measured via iperf. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
We send packets using a copy-free mechanism (this is the Guest to Host transport
via VMBUS). While this is obviously optimal for large packets,
it may not be optimal for small packets. Hyper-V host supports
a second mechanism for sending packets that is "copy based". We implement that
mechanism in this patch.

In this version of the patch I have addressed a comment from David Miller.

With this patch (and all of the other offload and VRSS patches), we are now able
to almost saturate a 10G interface between Linux VMs on Hyper-V
on different hosts - close to  9 Gbps as measured via iperf.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Simplify the send_completion variables 2014-04-23T18:48:39+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-04-21T21:54:44+00:00 893f66277799cd46bdf97429cc5d16a815a51273 The union contains only one member now, so we use the variables in it directly. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The union contains only one member now, so we use the variables in it directly.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Remove recv_pkt_list and lock 2014-04-23T18:48:39+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-04-21T21:54:43+00:00 4baab26129e0540746744232022110dbe9e011e7 Removed recv_pkt_list and lock, and updated related code, so that the locking overhead is reduced especially when multiple channels are in use. The recv_pkt_list isn't actually necessary because the packets are processed sequentially in each channel. It has been replaced by a local variable, and the related lock for this list is also removed. The is_data_pkt field is not used in receive path, so its assignment is cleaned up. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Removed recv_pkt_list and lock, and updated related code, so that
the locking overhead is reduced especially when multiple channels
are in use.

The recv_pkt_list isn't actually necessary because the packets are
processed sequentially in each channel. It has been replaced by a
local variable, and the related lock for this list is also removed.
The is_data_pkt field is not used in receive path, so its assignment
is cleaned up.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
hyperv: Add support for virtual Receive Side Scaling (vRSS) 2014-04-21T17:32:29+00:00 Haiyang Zhang haiyangz@microsoft.com 2014-04-21T17:20:28+00:00 5b54dac856cb5bd6f33f4159012773e4a33704f7 This feature allows multiple channels to be used by each virtual NIC. It is available on Hyper-V host 2012 R2. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
This feature allows multiple channels to be used by each virtual NIC.
It is available on Hyper-V host 2012 R2.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Drivers: net: hyperv: Address UDP checksum issues 2014-04-11T19:15:12+00:00 KY Srinivasan kys@microsoft.com 2014-04-09T22:00:47+00:00 af9893a3dc790ae0c4d3e68adde12bc3cb9c63fa ws2008r2 does not support UDP checksum offload. Thus, we cannnot turn on UDP offload in the host. Also, on ws2012 and ws2012 r2, there appear to be an issue with UDP checksum offload. Fix this issue by computing the UDP checksum in the Hyper-V driver. Based on Dave Miller's comments, in this version, I have COWed the skb before modifying the UDP header (the checksum field). Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
ws2008r2 does not support UDP checksum offload. Thus, we cannnot turn on
UDP offload in the host. Also, on ws2012 and ws2012 r2, there appear to be
an issue with UDP checksum offload.
Fix this issue by computing the UDP checksum in the Hyper-V driver.

Based on Dave Miller's comments, in this version, I have COWed the skb
before modifying the UDP header (the checksum field).

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>