RE: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS)
-Original Message- From: Daniel Borkmann [mailto:dbork...@redhat.com] Sent: Thursday, December 19, 2013 1:45 PM To: Haiyang Zhang Cc: Ben Hutchings; da...@davemloft.net; net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; jasow...@redhat.com; linux- ker...@vger.kernel.org; driverdev-devel@linuxdriverproject.org Subject: Re: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS) On 12/19/2013 07:36 PM, Haiyang Zhang wrote: Thank you for the suggestions! I will re-write the send queue selection, enhance the hash calculation, also fix the initialization sequence. Btw, Toeplitz hash function should either go into lib/hash.c as well or include/linux/hash.h to avoid ending up w/ various implementations in multiple places. Will do. Thanks, - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS)
-Original Message-
From: Ben Hutchings [mailto:bhutchi...@solarflare.com]
Sent: Thursday, December 19, 2013 12:46 PM
To: Haiyang Zhang
Cc: da...@davemloft.net; net...@vger.kernel.org; KY Srinivasan;
o...@aepfle.de; jasow...@redhat.com; linux-ker...@vger.kernel.org;
driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH net-next] hyperv: Add support for Virtual Receive Side
Scaling (vRSS)
On Wed, 2013-12-18 at 14:21 -0800, Haiyang Zhang wrote:
This feature allows multiple channels to be used by each virtual NIC.
It is available on Hyper-V host 2012 R2.
} else if (ret == -EAGAIN) {
- netif_stop_queue(ndev);
+ netif_tx_stop_all_queues(ndev);
if (atomic_read(net_device-num_outstanding_sends) 1) {
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
ret = -ENOSPC;
}
} else {
This doesn't makes any sense to me. How can you safely share the same
channels between all TX queues?
I think you need to associate TX queues and channels 1-1. If you are
required to
map packets to TX queues using the Toeplitz hash, you should implement
ndo_select_queue and do the mapping there. Then in
netvsc_send() you would use the queue number from the skb to find which
channel to use and which queue may need to be stopped/woken.
[...]
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
[...]
+/* Toeplitz hash function
+ * data: network byte order
+ * return: host byte order
+ */
This looks incredibly slow. I've seen software implementations that are
likely to
be more efficient, e.g.
http://thread.gmane.org/gmane.linux.network/284612/
[...]
int netvsc_probe(struct hv_device *dev,
return ret;
}
memcpy(net-dev_addr, device_info.mac_adr, ETH_ALEN);
+ nvdev = hv_get_drvdata(dev);
+ rtnl_lock();
+ netif_set_real_num_tx_queues(net, nvdev-num_chn);
+ netif_set_real_num_rx_queues(net, nvdev-num_chn);
[...]
These functions can fail if called after registering the net device, so you
should
either call them with the final values earlier or handle failure here.
Also, I notice that dev_addr is only set after registering; that should be
fixed.
Thank you for the suggestions! I will re-write the send queue selection, enhance
the hash calculation, also fix the initialization sequence.
Thanks,
- Haiyang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS)
From: Tom Herbert therb...@google.com Date: Thu, 19 Dec 2013 13:43:06 -0800 + u32 v, r; + int off, rem; + + off = idx / 8; + rem = idx % 8; + + v = (((unsigned int)key[off]) 24) + + (((unsigned int)key[off + 1]) 16) + + (((unsigned int)key[off + 2]) 8) + + (((unsigned int)key[off + 3])); + + r = v rem | (unsigned int)key[off + 4] (8 - rem); Minor nit, since the type you are using is u32, that's probably what you should be casting to in these spots instead of unsigned int. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS)
-Original Message- From: Tom Herbert [mailto:therb...@google.com] Sent: Thursday, December 19, 2013 4:43 PM To: Haiyang Zhang Cc: Daniel Borkmann; Ben Hutchings; da...@davemloft.net; net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; jasow...@redhat.com; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org Subject: Re: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS) Patch is below. This version did most pre-computation of the variants I built, but results in largest table (40*256*4 bytes), This gives performance roughly comparable with jhash (roughly same as jhash for IPv4, about 30% more cycles for IPv6). I have the simpler less memory intensive versions also if you're interested, these are 10x worse cycles so I wouldn't want those in critical path. Thank you for the code. We like the fast implementation even it uses a bit more memory. Are you going to address the comments and re-submit the code soon? Thanks, - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS)
-Original Message- From: Tom Herbert [mailto:therb...@google.com] Sent: Thursday, December 19, 2013 2:59 PM To: Haiyang Zhang Cc: Daniel Borkmann; Ben Hutchings; da...@davemloft.net; net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; jasow...@redhat.com; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org Subject: Re: [PATCH net-next] hyperv: Add support for Virtual Receive Side Scaling (vRSS) I posted an implementation of library functions for Toeplitz (see [PATCH 1/2] net: Toeplitz library functions). This includes some pre-computation of the table to get reasonable performance in the host. Please take a look. On the other hand, if you're computing a hash in the host, do you really need Toeplitz, flow_dissector already supports a good hash computation and can parse many more packets than just plain UDP/TCP. We probably only should be doing Toeplitz in the host if we need to match HW computed values. The Hyper-V host requires the guest to select channel based on Toeplitz hash, so we need to compute it on the guest. Regarding the Toeplitz function, do you mean this patch? http://patchwork.ozlabs.org/patch/277344/ This doesn't contain the implementation. Could you point me to the actual code? Thanks, - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
