netvsc NAPI patch process

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

How about if I send the vmbus patches through normal driver-devel upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
tree to get into 4.10?

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 26 Jan 2017 10:04:05 -0800

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

How about if I send the vmbus patches through normal driver-devel upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
tree to get into 4.10?

Another option is that the char-misc-next folks create a branch with just
the commits you need for NAPI, I pull that into net-next, and then you
can submit the NAPI changes to me.

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Thursday, January 26, 2017 10:04 AM
To: davem@davemloft.net; KY Srinivasan <kys@microsoft.com>; Greg KH
[off-list ref]
Cc: netdev@vger.kernel.org
Subject: netvsc NAPI patch process

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

In the past, we have done this in two stages - get the supporting vmbus patches into
Greg's tree first and in the next merge cycle get the netvsc patches in. Why not continue to
do what we have done in the past to address cross-tree dependencies.

Regards,

K. Y 

How about if I send the vmbus patches through normal driver-devel
upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-
net
tree to get into 4.10?

From: KY Srinivasan <kys@microsoft.com>
Date: Thu, 26 Jan 2017 20:46:40 +0000

In the past, we have done this in two stages - get the supporting
vmbus patches into Greg's tree first and in the next merge cycle get
the netvsc patches in. Why not continue to do what we have done in
the past to address cross-tree dependencies.

It takes too damn long.

On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 26 Jan 2017 10:04:05 -0800

quoted

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

How about if I send the vmbus patches through normal driver-devel upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
tree to get into 4.10?

Another option is that the char-misc-next folks create a branch with just
the commits you need for NAPI, I pull that into net-next, and then you
can submit the NAPI changes to me.

I can easily do that, or I have no problem with the vmbus changes going
through the net-next tree, if they are sane (i.e. let me review them
please...)  Which ever is easier for the networking developers, their
tree is much crazier than the tiny char-misc tree is :)

thanks,

greg k-h

On Fri, Jan 27, 2017 at 09:39:53AM -0800, Stephen Hemminger wrote:

On Fri, 27 Jan 2017 08:54:06 +0100
Greg KH [off-list ref] wrote:

quoted

On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:

quoted

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 26 Jan 2017 10:04:05 -0800
  

quoted

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

How about if I send the vmbus patches through normal driver-devel upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
tree to get into 4.10?  

Another option is that the char-misc-next folks create a branch with just
the commits you need for NAPI, I pull that into net-next, and then you
can submit the NAPI changes to me.  

I can easily do that, or I have no problem with the vmbus changes going
through the net-next tree, if they are sane (i.e. let me review them
please...)  Which ever is easier for the networking developers, their
tree is much crazier than the tiny char-misc tree is :)

thanks,

greg k-h

I just want the least pain and the least overhead process. Waiting two releases
and trying to deal with merge conflicts is a pain. Also it makes life harder
with distro backports etc.

I totally agree.  Post the patches and let's see what they look like and
then we can argue who's tree they should go through :)

On Fri, 27 Jan 2017 08:54:06 +0100
Greg KH [off-list ref] wrote:

On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:

quoted

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 26 Jan 2017 10:04:05 -0800
  

quoted

I have a working set of patches to enable NAPI in the netvsc driver.
The problem is that it requires a set of patches to vmbus layer as well.
Since vmbus patches have been going through char-misc-next tree rather
than net-next, it is difficult to stage these.

How about if I send the vmbus patches through normal driver-devel upstream
and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
tree to get into 4.10?  

Another option is that the char-misc-next folks create a branch with just
the commits you need for NAPI, I pull that into net-next, and then you
can submit the NAPI changes to me.  

I can easily do that, or I have no problem with the vmbus changes going
through the net-next tree, if they are sane (i.e. let me review them
please...)  Which ever is easier for the networking developers, their
tree is much crazier than the tiny char-misc tree is :)

thanks,

greg k-h

I just want the least pain and the least overhead process. Waiting two releases
and trying to deal with merge conflicts is a pain. Also it makes life harder
with distro backports etc.