tdev@vger.kernel.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com
> > Subject: Re: [PATCH net-next 1/1] hv_netvsc: Properly size the vrss queues
> >
> > Since you're redoing this anyway.
&g
t; a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Properly size the vrss queues
>
> Since you're redoing this anyway.
>
> On Tue, May 26, 2015 at 04:21:09PM -0700, K. Y. Srinivasan wrote:
> > diff --git a/drivers/net/hyperv/h
Since you're redoing this anyway.
On Tue, May 26, 2015 at 04:21:09PM -0700, K. Y. Srinivasan wrote:
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index ddcc7f8..dd45440 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@
; jasow...@redhat.com
> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Properly size the vrss queues
>
> From: "K. Y. Srinivasan"
> Date: Tue, 26 May 2015 16:21:09 -0700
>
> > The current algorithm for deciding on the number of VRSS channels is
> > not optimal
From: "K. Y. Srinivasan"
Date: Tue, 26 May 2015 16:21:09 -0700
> The current algorithm for deciding on the number of VRSS channels is
> not optimal since we open up the min of number of CPUs online and the
> number of VRSS channels the host is offering. So on a 32 VCPU guest
> we could potentiall
The current algorithm for deciding on the number of VRSS channels is
not optimal since we open up the min of number of CPUs online and the
number of VRSS channels the host is offering. So on a 32 VCPU guest
we could potentially open 32 VRSS subchannels. Experimentation has
shown that it is best to