Re: netvsc NAPI

2017-02-23 Thread Stephen Hemminger
On Thu, 23 Feb 2017 18:24:06 -0500 (EST)
David Miller  wrote:

> From: Stephen Hemminger 
> Date: Wed, 22 Feb 2017 09:33:16 -0800
> 
> > NAPI for netvsc is ready but the merge coordination is a nuisance.
> > 
> > Since netvsc NAPI support requires other changes that are proceeding through
> > GregKH's char-misc tree. I would like to send the two patches after current 
> > net-next
> > and char-misc-next are merged into Linus's tree.
> > 
> > Need these (at a minimum) these changes
> > 
> >  6e47dd3e2938 ("vmbus: expose hv_begin/end_read")
> >  5529eaf6e79a ("vmbus: remove conditional locking of vmbus_write")
> >  b71e328297a3 ("vmbus: add direct isr callback mode")
> >  631e63a9f346 ("vmbus: change to per channel tasklet")
> >  37cdd991fac8 ("vmbus: put related per-cpu variable together")
> > 
> > Please let me know when linux-net is up to date with these.  
> 
> The 'net' tree is now current with Linus's current tree, and all of
> those above commits seem to be there.

Great thanks. I will merge the NAPI and retest.


Re: netvsc NAPI

2017-02-23 Thread David Miller
From: Stephen Hemminger 
Date: Wed, 22 Feb 2017 09:33:16 -0800

> NAPI for netvsc is ready but the merge coordination is a nuisance.
> 
> Since netvsc NAPI support requires other changes that are proceeding through
> GregKH's char-misc tree. I would like to send the two patches after current 
> net-next
> and char-misc-next are merged into Linus's tree.
> 
> Need these (at a minimum) these changes
> 
>  6e47dd3e2938 ("vmbus: expose hv_begin/end_read")
>  5529eaf6e79a ("vmbus: remove conditional locking of vmbus_write")
>  b71e328297a3 ("vmbus: add direct isr callback mode")
>  631e63a9f346 ("vmbus: change to per channel tasklet")
>  37cdd991fac8 ("vmbus: put related per-cpu variable together")
> 
> Please let me know when linux-net is up to date with these.

The 'net' tree is now current with Linus's current tree, and all of
those above commits seem to be there.


Re: netvsc NAPI patch process

2017-01-27 Thread Stephen Hemminger
On Fri, 27 Jan 2017 08:54:06 +0100
Greg KH  wrote:

> On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:
> > From: Stephen Hemminger 
> > 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.  
> 
> 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.


Re: netvsc NAPI patch process

2017-01-27 Thread Greg KH
On Fri, Jan 27, 2017 at 09:39:53AM -0800, Stephen Hemminger wrote:
> On Fri, 27 Jan 2017 08:54:06 +0100
> Greg KH  wrote:
> 
> > On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:
> > > From: Stephen Hemminger 
> > > 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.  
> > 
> > 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 :)


Re: netvsc NAPI patch process

2017-01-26 Thread Greg KH
On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:
> From: Stephen Hemminger 
> 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.

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


Re: netvsc NAPI patch process

2017-01-26 Thread David Miller
From: KY Srinivasan 
Date: Thu, 26 Jan 2017 20:46:40 +

> 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.


RE: netvsc NAPI patch process

2017-01-26 Thread KY Srinivasan


> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, January 26, 2017 10:04 AM
> To: da...@davemloft.net; KY Srinivasan ; Greg KH
> 
> 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?


Re: netvsc NAPI patch process

2017-01-26 Thread David Miller
From: Stephen Hemminger 
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.