interdependencies with cxgb4 and iw_cxgb4

interdependencies with cxgb4 and iw_cxgb4

[Steve Wise]

Hey Dave,

We've been discussing dependency issues between cxgb4 and the upper layer
drivers including iw_cxgb4 on linux-rdma [1], and I want to broaden this
discussion to include netdev and you, since this involves both linux-rdma
and netdev.   (note the SRQ patch submission that triggered this discussion
was sent to linux-rdma, but it should have also included netdev.  This was
an oversight and will be corrected on the next submission depending on how
chelsio decides to proceed)

In a nutshell, Chelsio has a few patch series to submit that require
enabling some feature in cxgb4 that is then used by iw_cxgb4. SRQ support is
one such series.   The series as a whole spans both netdev and linux-rdma
maintainers.  Because of the compile dependency between iw_cxgb4 and cxgb4
introduced by this series,  the cxgb4 parts and iw_cxgb4 parts cannot be
split across maintainers.  Further, if one maintainer merges the entire
series, then there are issues if commits are submitted to the other
maintainer that conflict.

This issue has also been dealt-with for Mellanox drivers, I believe.  I take
it the solution for them was a k.o. signed repo, that they maintain, where
both linux-rdma and netdev take PRs from for commits that are needed in both
repos.   Then these are reconciled when both repos are merged into Linus'
repo. (I hope my understanding of this is correct)

For Chelsio, this is perhaps a possibility, but I'm wondering if there is a
simpler solution?  A few other option we've been discussing include:

1) submit the cxgb4-only changes to netdev in release cycle X, and then only
submit the iw_cxgb4 (or other upper drivers) changes that use them in
release cycle X+1.  The pro of this is simplicity.  The con is timeliness -
it takes 2 release cycles to get the feature upstream.

2) run the entire series through one maintainer's repo (with all
maintainers' ACK on the content and plan, of course), and ensuring no
conflicting commits are submitted for the rest of that release cycle.  I'm
not really sure that this is feasible given anyone could create commits for
upstream drivers.  So how could Chelsio really control this?

Do you have any suggestions on how we should proceed?  

[1] https://www.spinics.net/lists/linux-rdma/msg61856.html

Thanks,

Steve.

Re: interdependencies with cxgb4 and iw_cxgb4

[David Miller]

From: "Steve Wise" <swise@opengridcomputing.com>
Date: Wed, 14 Mar 2018 10:31:24 -0500

> This issue has also been dealt-with for Mellanox drivers, I believe.  I take
> it the solution for them was a k.o. signed repo, that they maintain, where
> both linux-rdma and netdev take PRs from for commits that are needed in both
> repos.   Then these are reconciled when both repos are merged into Linus'
> repo. (I hope my understanding of this is correct)
> 
> For Chelsio, this is perhaps a possibility, but I'm wondering if there is a
> simpler solution?  A few other option we've been discussing include:
> 
> 1) submit the cxgb4-only changes to netdev in release cycle X, and then only
> submit the iw_cxgb4 (or other upper drivers) changes that use them in
> release cycle X+1.  The pro of this is simplicity.  The con is timeliness -
> it takes 2 release cycles to get the feature upstream.
> 
> 2) run the entire series through one maintainer's repo (with all
> maintainers' ACK on the content and plan, of course), and ensuring no
> conflicting commits are submitted for the rest of that release cycle.  I'm
> not really sure that this is feasible given anyone could create commits for
> upstream drivers.  So how could Chelsio really control this?
> 
> Do you have any suggestions on how we should proceed?  

I think the Mellanox setup is working well currently.

If the changes get pulled into both the rdma and networking tree, then it
all gets resolved cleanly no matter which of rdma or networking goes into
Linus's tree first during the merge window.

It doesn't have the delay issues of suggestion #1, and I think avoiding
conflicts in situation #2 is next to impossible.

In fact, such conflict problems are how we arrived at the approach
Mellanox is using in the first place.

Re: interdependencies with cxgb4 and iw_cxgb4

[Steve Wise]

On 3/16/2018 11:21 AM, David Miller wrote:
> From: "Steve Wise" <swise@opengridcomputing.com>
> Date: Wed, 14 Mar 2018 10:31:24 -0500
>
>> This issue has also been dealt-with for Mellanox drivers, I believe.  I take
>> it the solution for them was a k.o. signed repo, that they maintain, where
>> both linux-rdma and netdev take PRs from for commits that are needed in both
>> repos.   Then these are reconciled when both repos are merged into Linus'
>> repo. (I hope my understanding of this is correct)
>>
>> For Chelsio, this is perhaps a possibility, but I'm wondering if there is a
>> simpler solution?  A few other option we've been discussing include:
>>
>> 1) submit the cxgb4-only changes to netdev in release cycle X, and then only
>> submit the iw_cxgb4 (or other upper drivers) changes that use them in
>> release cycle X+1.  The pro of this is simplicity.  The con is timeliness -
>> it takes 2 release cycles to get the feature upstream.
>>
>> 2) run the entire series through one maintainer's repo (with all
>> maintainers' ACK on the content and plan, of course), and ensuring no
>> conflicting commits are submitted for the rest of that release cycle.  I'm
>> not really sure that this is feasible given anyone could create commits for
>> upstream drivers.  So how could Chelsio really control this?
>>
>> Do you have any suggestions on how we should proceed?
> I think the Mellanox setup is working well currently.
>
> If the changes get pulled into both the rdma and networking tree, then it
> all gets resolved cleanly no matter which of rdma or networking goes into
> Linus's tree first during the merge window.
>
> It doesn't have the delay issues of suggestion #1, and I think avoiding
> conflicts in situation #2 is next to impossible.
>
> In fact, such conflict problems are how we arrived at the approach
> Mellanox is using in the first place.
>

Thanks Dave.

Let me ask a dumb question:  Why cannot one of the maintaners pull the 
commit from the other mainainer's git repo directly?  IE why have this 
third trusted/signed git repo that has to be on k.o, from which both 
maintainers pull?  If one of you can pull it in via a patch series, like 
you do for all other patches, and then notify the other maintainer to 
pull it from the first maintainers' repo if the series meets the 
requirements that it needs to be in both maintainers' repositories?  
This avoids adding more staging git repos on k.o.  But probably I'm 
missing something...

Steve.

Re: interdependencies with cxgb4 and iw_cxgb4

[David Miller]

From: Steve Wise <swise@opengridcomputing.com>
Date: Mon, 19 Mar 2018 14:50:57 -0500

> Let me ask a dumb question:� Why cannot one of the maintaners pull the
> commit from the other mainainer's git repo directly?� IE why have this
> third trusted/signed git repo that has to be on k.o, from which both
> maintainers pull?� If one of you can pull it in via a patch series,
> like you do for all other patches, and then notify the other
> maintainer to pull it from the first maintainers' repo if the series
> meets the requirements that it needs to be in both maintainers'
> repositories?� This avoids adding more staging git repos on k.o.� But
> probably I'm missing something...

Tree A may not want all of tree B's changes, and vice versa.

RE: interdependencies with cxgb4 and iw_cxgb4

[Steve Wise]

> From: Steve Wise <swise@opengridcomputing.com>
> Date: Mon, 19 Mar 2018 14:50:57 -0500
> 
> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
> > commit from the other mainainer's git repo directly?� IE why have this
> > third trusted/signed git repo that has to be on k.o, from which both
> > maintainers pull?� If one of you can pull it in via a patch series,
> > like you do for all other patches, and then notify the other
> > maintainer to pull it from the first maintainers' repo if the series
> > meets the requirements that it needs to be in both maintainers'
> > repositories?� This avoids adding more staging git repos on k.o.� But
> > probably I'm missing something...
> 
> Tree A may not want all of tree B's changes, and vice versa.

I was thinking the special commit would go into a branch that was based on,
say rc1 or rc2 of one of the maintainers.  Then both maintainers pull that
into their -next branch.  Would that work?

Re: interdependencies with cxgb4 and iw_cxgb4

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Tue, Mar 20, 2018 at 08:47:04AM -0500, Steve Wise wrote:
> > From: Steve Wise <swise@opengridcomputing.com>
> > Date: Mon, 19 Mar 2018 14:50:57 -0500
> >
> > > Let me ask a dumb question:  Why cannot one of the maintaners pull the
> > > commit from the other mainainer's git repo directly?  IE why have this
> > > third trusted/signed git repo that has to be on k.o, from which both
> > > maintainers pull?  If one of you can pull it in via a patch series,
> > > like you do for all other patches, and then notify the other
> > > maintainer to pull it from the first maintainers' repo if the series
> > > meets the requirements that it needs to be in both maintainers'
> > > repositories?  This avoids adding more staging git repos on k.o.  But
> > > probably I'm missing something...
> >
> > Tree A may not want all of tree B's changes, and vice versa.
>
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers.  Then both maintainers pull that
> into their -next branch.  Would that work?

Steve,

It is more or less what we are doing with our shared PR, we just
"offloaded" the overhead of creating and maintaining that special
branch from maintainers. I don't think that anyone here will say no
to you to create that special branch from time to time.

Thanks

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: interdependencies with cxgb4 and iw_cxgb4

[David Miller]

From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 08:47:04 -0500

>> From: Steve Wise <swise@opengridcomputing.com>
>> Date: Mon, 19 Mar 2018 14:50:57 -0500
>> 
>> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
>> > commit from the other mainainer's git repo directly?� IE why have this
>> > third trusted/signed git repo that has to be on k.o, from which both
>> > maintainers pull?� If one of you can pull it in via a patch series,
>> > like you do for all other patches, and then notify the other
>> > maintainer to pull it from the first maintainers' repo if the series
>> > meets the requirements that it needs to be in both maintainers'
>> > repositories?� This avoids adding more staging git repos on k.o.� But
>> > probably I'm missing something...
>> 
>> Tree A may not want all of tree B's changes, and vice versa.
> 
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers.  Then both maintainers pull that
> into their -next branch.  Would that work?

That makes things more complicated.

The simplest design is that "identical" commits end up in both the
RDMA and the net-next tree.

Then it absolutely doesn't matter whose tree goes into Linus's first.

Also, we should not be merging "merge window" code after -rc1.  "-rc1"
means the merge window is closed.

RE: interdependencies with cxgb4 and iw_cxgb4

[Steve Wise]

> >> > Let me ask a dumb question:� Why cannot one of the maintaners pull
> the
> >> > commit from the other mainainer's git repo directly?� IE why have
this
> >> > third trusted/signed git repo that has to be on k.o, from which both
> >> > maintainers pull?� If one of you can pull it in via a patch series,
> >> > like you do for all other patches, and then notify the other
> >> > maintainer to pull it from the first maintainers' repo if the series
> >> > meets the requirements that it needs to be in both maintainers'
> >> > repositories?� This avoids adding more staging git repos on k.o.� But
> >> > probably I'm missing something...
> >>
> >> Tree A may not want all of tree B's changes, and vice versa.
> >
> > I was thinking the special commit would go into a branch that was based
> on,
> > say rc1 or rc2 of one of the maintainers.  Then both maintainers pull
that
> > into their -next branch.  Would that work?
> 
> That makes things more complicated.

For the maintainers, yes.  But it avoids setting up k.o accounts and git
repos for each device driver maintainer that has this issue.

> 
> The simplest design is that "identical" commits end up in both the
> RDMA and the net-next tree.
> 
> Then it absolutely doesn't matter whose tree goes into Linus's first.
> 

Yes, and that would still be the case, from my understanding:  Instead of
each driver having a k.o. signed git repo, we ask the maintainers to stage
this common branch that both maintainers pull from into their -next
branches/repos.


> Also, we should not be merging "merge window" code after -rc1.  "-rc1"
> means the merge window is closed.

I meant using rc-1 for the current release when submitting these shared
commits for the _following merge window_.

Steve.

Re: interdependencies with cxgb4 and iw_cxgb4

[David Miller]

From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 10:08:44 -0500

> For the maintainers, yes.  But it avoids setting up k.o accounts and
> git repos for each device driver maintainer that has this issue.

I think this is quite a reasonable requirement for submitters wishing
to make significant changes across two subsystems with complex
interdependencies.

It is critical to get the changes tested in both the RDMA and net-next
tree contexts as early as possible, and to shake out any intergration
issues (which happens transparently via linux-next).

I know it's easy to see the personal "burdon" it causes you as an
individual developer, but you really have to consider how much is
in-flight and being dealt with by maintainers of very active
subsystems like the networking.

Thank you.

RE: interdependencies with cxgb4 and iw_cxgb4

[Steve Wise]

> 
> From: "Steve Wise" <swise@opengridcomputing.com>
> Date: Tue, 20 Mar 2018 10:08:44 -0500
> 
> > For the maintainers, yes.  But it avoids setting up k.o accounts and
> > git repos for each device driver maintainer that has this issue.
> 
> I think this is quite a reasonable requirement for submitters wishing
> to make significant changes across two subsystems with complex
> interdependencies.
> 
> It is critical to get the changes tested in both the RDMA and net-next
> tree contexts as early as possible, and to shake out any intergration
> issues (which happens transparently via linux-next).
> 
> I know it's easy to see the personal "burdon" it causes you as an
> individual developer, but you really have to consider how much is
> in-flight and being dealt with by maintainers of very active
> subsystems like the networking.
> 
> Thank you.

Fair enough.  Thanks Dave.