On Wed, Apr 30, 2014 at 10:14:31AM -0700, K. Y. Srinivasan wrote:
> + /* Setup state for managing the send buffer. */
> + net_device->map_words = DIV_ROUND_UP(net_device->send_section_cnt,
> + BITS_PER_LONG);
> +
> + net_device->send_section_map
From: "K. Y. Srinivasan"
Date: Wed, 30 Apr 2014 10:14:31 -0700
> 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 mechani
From: KY Srinivasan
Date: Wed, 30 Apr 2014 14:17:04 +
> Please let me know if there is some other issue you want addressed in this
> patch.
If the patch isn't in patchwork, I'm not going to apply it and you need to
simply resubmit it.
___
devel ma
> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Wednesday, April 23, 2014 2:25 PM
> To: da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
>
On Thu, Apr 24, 2014 at 10:06:24PM +, KY Srinivasan wrote:
> > From: Andev [mailto:debian...@gmail.com]
> > Your use of goto exit/cleanup in some functions and returning directly on
> > errors in others could use a cleanup. Please consider doing that while you
> > are
> > touching those files.
hat.com
> Subject: Re: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on
> the send path
>
> On Wed, Apr 23, 2014 at 5:24 PM, K. Y. Srinivasan
> wrote:
>
> > drivers/net/hyperv/hyperv_net.h | 14 +++
> > drivers/net/hyperv/netvsc.c | 226
> +
On Wed, Apr 23, 2014 at 5:24 PM, K. Y. Srinivasan wrote:
> drivers/net/hyperv/hyperv_net.h | 14 +++
> drivers/net/hyperv/netvsc.c | 226
> +--
> drivers/net/hyperv/netvsc_drv.c |3 +-> 3 files changed, 234
> insertions(+), 9 deletions(-)
I just
TLDR; Style nits and we should return -ENOMEM on error instead of
success.
On Wed, Apr 23, 2014 at 02:24:45PM -0700, K. Y. Srinivasan wrote:
> 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
