HFI1 code duplication todo

HFI1 code duplication todo

[Dennis Dalessandro]

The major todo for the hfi1 driver in staging is getting rid of the verbs 
code duplication between ipath, qib, and now hfi1. The ipath driver has been 
deprecated and is going to be deleted soon. So that leaves qib and hfi. To 
address this we have proposed rdmavt which will be a common kmod that 
provides software RDMA verbs support. qib and hfi1 will both use this as 
well as other forthcoming drivers such as soft-roce. See this thread for 
some details: http://www.spinics.net/lists/linux-rdma/msg29922.html.

Since that initial RFC we have been accumulating patches in a GitHub repo 
for an early look at the development. At some point soon we want to actually 
start posting the patches to the mailing list. This is where it gets tricky.  
The code basically not only adds a new driver but it modifies two existing 
ones, heavily. To make it more murky one driver is in staging the other is 
in the usual drivers/infiniband tree.

The question is, how do we go about this logistically due to the 2 drivers 
being in separate sub-trees?

Greg, Doug,
As the maintainers of the two trees involved we'd kind of like to get your 
thoughts on this.

Thanks

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

Re: HFI1 code duplication todo

[Dennis Dalessandro]

On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
>The major todo for the hfi1 driver in staging is getting rid of the verbs 
>code duplication between ipath, qib, and now hfi1. The ipath driver has 
>been deprecated and is going to be deleted soon. So that leaves qib and 
>hfi. To address this we have proposed rdmavt which will be a common kmod 
>that provides software RDMA verbs support. qib and hfi1 will both use this 
>as well as other forthcoming drivers such as soft-roce. See this thread for 
>some details: http://www.spinics.net/lists/linux-rdma/msg29922.html.
>
>Since that initial RFC we have been accumulating patches in a GitHub repo 
>for an early look at the development. At some point soon we want to 
>actually start posting the patches to the mailing list. This is where it 
>gets tricky.  The code basically not only adds a new driver but it modifies 
>two existing ones, heavily. To make it more murky one driver is in staging 
>the other is in the usual drivers/infiniband tree.
>
>The question is, how do we go about this logistically due to the 2 drivers 
>being in separate sub-trees?
>
>Greg, Doug,
>As the maintainers of the two trees involved we'd kind of like to get your 
>thoughts on this.

Hi Greg and Doug,

Just wanted to ping you guys again in case my mail last week slipped through 
the cracks. We are at the point now where we have some patches we can start 
posting. Looking for some logistical guidance.

Thanks

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

Re: HFI1 code duplication todo

[Dan Carpenter]

At the beginning when hfi1 was put into staging, then it was easy enough
for Greg to take those patches but now it feels awkward.  Probably
Doug and the linux-rdma@vger.kernel.org people should start maintaining
the drivers/staging/rdma directory.  Like merge Greg's tree and pull in
whatever checkpatch fixes are still on the list and then take over from
there...

regards,
dan carpenter

Re: HFI1 code duplication todo

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2864 bytes --]

On 11/19/2015 05:23 PM, Dennis Dalessandro wrote:
> On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
>> The major todo for the hfi1 driver in staging is getting rid of the
>> verbs code duplication between ipath, qib, and now hfi1. The ipath
>> driver has been deprecated and is going to be deleted soon. So that
>> leaves qib and hfi. To address this we have proposed rdmavt which will
>> be a common kmod that provides software RDMA verbs support. qib and
>> hfi1 will both use this as well as other forthcoming drivers such as
>> soft-roce. See this thread for some details:
>> http://www.spinics.net/lists/linux-rdma/msg29922.html.
>>
>> Since that initial RFC we have been accumulating patches in a GitHub
>> repo for an early look at the development. At some point soon we want
>> to actually start posting the patches to the mailing list. This is
>> where it gets tricky.  The code basically not only adds a new driver
>> but it modifies two existing ones, heavily. To make it more murky one
>> driver is in staging the other is in the usual drivers/infiniband tree.
>>
>> The question is, how do we go about this logistically due to the 2
>> drivers being in separate sub-trees?
>>
>> Greg, Doug,
>> As the maintainers of the two trees involved we'd kind of like to get
>> your thoughts on this.
> 
> Hi Greg and Doug,
> 
> Just wanted to ping you guys again in case my mail last week slipped
> through the cracks. We are at the point now where we have some patches
> we can start posting. Looking for some logistical guidance.

Sorry, I've been out for a while now with the birth of my second child.
 Things have settled down enough around here that I should be able to
get things going again (at least well enough to be more responsive to
email anyway).

So, as to the hfi1/qib/rxe transport library.  The qib driver is in the
rdma tree, and we aren't going to move it to staging just because it
depends on something in staging, so we need to start adding the library
in the core tree to avoid dependency issues.  As for the hfi1 driver,
I'm of the opinion that putting it in staging because of the code
duplication issue was probably not the right thing to do.  It's
benefited from the extra eyes on it to help make it a better driver, but
I think I'm ready to move it to the main RDMA tree and start working on
it from there where there won't be any cross tree dependency issues.

To that end, I've opened my 4.4-rc branch and deleted the three
deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
sent an email to Linus to see if he's ok taking those changes, and if
so, I'll get them submitted and then open up my for-4.5 branch early to
be able to start taking for-next patches.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: HFI1 code duplication todo

[Marciniszyn, Mike]

> 
> To that end, I've opened my 4.4-rc branch and deleted the three deprecated
> drivers from staging and moved hfi1 to the rdma tree.  I've sent an email to
> Linus to see if he's ok taking those changes, and if so, I'll get them submitted
> and then open up my for-4.5 branch early to be able to start taking for-next
> patches.
> 

There are inflight patches in two states right now:
1. Accepted into staging testing
2. Being debated on the list.

How do we want to handle those?

I would hate to miss a patch.

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

Re: HFI1 code duplication todo

[Greg KH]

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> To that end, I've opened my 4.4-rc branch and deleted the three
> deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
> sent an email to Linus to see if he's ok taking those changes, and if
> so, I'll get them submitted and then open up my for-4.5 branch early to
> be able to start taking for-next patches.

I think it's too late for that, especially given that I have 34+ patches
for the staging rdma drivers already in my tree in linux-next.  And the
hfil1 code really doesn't look like its ready to merge into the "real"
portion of the kernel tree, given the horrid nature of the patches
submitted recently for it :(

I had expected the drivers to be deleted for -rc1, removing them now
seems a bit late in the merge window.

thanks,

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

Re: HFI1 code duplication todo

[Doug Ledford]

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

On 11/20/2015 11:39 AM, Greg KH wrote:
> On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
>> To that end, I've opened my 4.4-rc branch and deleted the three
>> deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
>> sent an email to Linus to see if he's ok taking those changes, and if
>> so, I'll get them submitted and then open up my for-4.5 branch early to
>> be able to start taking for-next patches.
> 
> I think it's too late for that, especially given that I have 34+ patches
> for the staging rdma drivers already in my tree in linux-next.

For hfi1 rename detection should work, for the other three, patches to
removed files are easily resolved as simply dropped patches.  So I don't
think it's that large of an issue.  Correct me if I'm wrong.

>  And the
> hfil1 code really doesn't look like its ready to merge into the "real"
> portion of the kernel tree, given the horrid nature of the patches
> submitted recently for it :(

I'm sorry, that doesn't make sense to me.  How can the quality of
patches that aren't part of the driver yet and are just being submitted
impune the readiness of the code the patches are supposed to be touching?

And that's orthogonal to the issue that the primary TODO item for this
driver requires coordination between it, qib (in the RDMA tree), and the
upcoming soft_roce driver.  If the driver isn't moved, then we have to
coordinate between your tree and mine to make sure that no patches are
taken into your tree until after the patches they depend on have landed
in my tree.  And then you tree likely won't build unless you pull from
my tree and merge up first.  It's not really tenable.  That was why I
had suggested (and originally you agreed to) that I would handle the
entire staging/rdma tree.  However, since you changed your mind on that
issue, we now have this coordination issue.  I don't really want to deal
with that, so I would rather move the hfi1 driver and take care of the
all the needed patching myself going forward.

> I had expected the drivers to be deleted for -rc1, removing them now
> seems a bit late in the merge window.

Yes, I know.  I've been busy.  My apologies for not getting it in prior
to rc1.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: HFI1 code duplication todo

[Christoph Hellwig]

Hi Doug,

before the drivers stops overloading writev vs write (hfi1_file_ops)
it MUST not be moved to the main tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HFI1 code duplication todo

[Greg KH]

On Fri, Nov 20, 2015 at 11:58:18AM -0500, Doug Ledford wrote:
> On 11/20/2015 11:39 AM, Greg KH wrote:
> > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> >> To that end, I've opened my 4.4-rc branch and deleted the three
> >> deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
> >> sent an email to Linus to see if he's ok taking those changes, and if
> >> so, I'll get them submitted and then open up my for-4.5 branch early to
> >> be able to start taking for-next patches.
> > 
> > I think it's too late for that, especially given that I have 34+ patches
> > for the staging rdma drivers already in my tree in linux-next.
> 
> For hfi1 rename detection should work, for the other three, patches to
> removed files are easily resolved as simply dropped patches.  So I don't
> think it's that large of an issue.  Correct me if I'm wrong.

I don't know what kind of conflicts will happen, if the changes will
propagate over if you rename a file in one branch and expect the changes
made to the file in a different branch to come over.  Haven't done that
in years.

> >  And the
> > hfil1 code really doesn't look like its ready to merge into the "real"
> > portion of the kernel tree, given the horrid nature of the patches
> > submitted recently for it :(
> 
> I'm sorry, that doesn't make sense to me.  How can the quality of
> patches that aren't part of the driver yet and are just being submitted
> impune the readiness of the code the patches are supposed to be touching?

They imply that the quality of the existing code is very low, if the
authors can't submit valid changes to the existing files :)

> And that's orthogonal to the issue that the primary TODO item for this
> driver requires coordination between it, qib (in the RDMA tree), and the
> upcoming soft_roce driver.  If the driver isn't moved, then we have to
> coordinate between your tree and mine to make sure that no patches are
> taken into your tree until after the patches they depend on have landed
> in my tree.  And then you tree likely won't build unless you pull from
> my tree and merge up first.  It's not really tenable.  That was why I
> had suggested (and originally you agreed to) that I would handle the
> entire staging/rdma tree.  However, since you changed your mind on that
> issue, we now have this coordination issue.  I don't really want to deal
> with that, so I would rather move the hfi1 driver and take care of the
> all the needed patching myself going forward.

That might be the _primary_ TODO item, but really, look at the patches
being submitted so far, they are just fixing up basic things that should
have been done a long time ago to the codebase.  How about people get it
cleaned up "completely" for this merge cycle, going through my tree, and
then, when it's all cleaned up, I'll move it to your portion of the tree
and merge that into 4.5-rc1 and then the cross-driver/core changes you
are referring to can happen.  There's no big rush here to try to force
the issue.

> > I had expected the drivers to be deleted for -rc1, removing them now
> > seems a bit late in the merge window.
> 
> Yes, I know.  I've been busy.  My apologies for not getting it in prior
> to rc1.

It's not a problem, life happens (congratulations by the way), but don't
rush things now, why not just wait until the next merge window, there
are no deadlines here that require this to happen for 4.4-final.

thanks,

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

Re: HFI1 code duplication todo

[Doug Ledford]

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

On 11/20/2015 12:13 PM, Greg KH wrote:

>>> I think it's too late for that, especially given that I have 34+ patches
>>> for the staging rdma drivers already in my tree in linux-next.
>>
>> For hfi1 rename detection should work, for the other three, patches to
>> removed files are easily resolved as simply dropped patches.  So I don't
>> think it's that large of an issue.  Correct me if I'm wrong.
> 
> I don't know what kind of conflicts will happen, if the changes will
> propagate over if you rename a file in one branch and expect the changes
> made to the file in a different branch to come over.  Haven't done that
> in years.

Well, there's also the possibility of just me pulling your current
for-next and making that the starting point of my for-next and doing the
deletions and move there.  That would resolve the issue.

>> And that's orthogonal to the issue that the primary TODO item for this
>> driver requires coordination between it, qib (in the RDMA tree), and the
>> upcoming soft_roce driver.  If the driver isn't moved, then we have to
>> coordinate between your tree and mine to make sure that no patches are
>> taken into your tree until after the patches they depend on have landed
>> in my tree.  And then you tree likely won't build unless you pull from
>> my tree and merge up first.  It's not really tenable.  That was why I
>> had suggested (and originally you agreed to) that I would handle the
>> entire staging/rdma tree.  However, since you changed your mind on that
>> issue, we now have this coordination issue.  I don't really want to deal
>> with that, so I would rather move the hfi1 driver and take care of the
>> all the needed patching myself going forward.
> 
> That might be the _primary_ TODO item, but really, look at the patches
> being submitted so far, they are just fixing up basic things that should
> have been done a long time ago to the codebase.

Yes, I agree.  The driver is in active development.  It is not a mature
driver, and they are still fixing things up.

>  How about people get it
> cleaned up "completely" for this merge cycle, going through my tree, and
> then, when it's all cleaned up, I'll move it to your portion of the tree
> and merge that into 4.5-rc1 and then the cross-driver/core changes you
> are referring to can happen.  There's no big rush here to try to force
> the issue.

Other than the fact that people are ready to start on the initial
changes to support the library, there's no rush.  But doing the move now
(even if just via my for-next branch) allows people to start submitting
those other patches.  There are multiple people working on this driver,
some of them working on cleaning the driver up in general, and some
working on that transition to a core library for transfers.  Getting the
driver moved allows those people to submit patches in parallel instead
of forcing serialization of the development flow.

>>> I had expected the drivers to be deleted for -rc1, removing them now
>>> seems a bit late in the merge window.
>>
>> Yes, I know.  I've been busy.  My apologies for not getting it in prior
>> to rc1.
> 
> It's not a problem, life happens (congratulations by the way),

Thanks :-)

> but don't
> rush things now, why not just wait until the next merge window, there
> are no deadlines here that require this to happen for 4.4-final.

I'm actually not in a rush to get the deletions in, or to get the
cleanup patches to hfi1 in, I'm only trying to enable getting the
library development started.  Right now, it's blocked.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: HFI1 code duplication todo

[ira.weiny]

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> On 11/19/2015 05:23 PM, Dennis Dalessandro wrote:
> > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
> >> The major todo for the hfi1 driver in staging is getting rid of the
> >> verbs code duplication between ipath, qib, and now hfi1. The ipath
> >> driver has been deprecated and is going to be deleted soon. So that
> >> leaves qib and hfi. To address this we have proposed rdmavt which will
> >> be a common kmod that provides software RDMA verbs support. qib and
> >> hfi1 will both use this as well as other forthcoming drivers such as
> >> soft-roce. See this thread for some details:
> >> http://www.spinics.net/lists/linux-rdma/msg29922.html.
> >>
> >> Since that initial RFC we have been accumulating patches in a GitHub
> >> repo for an early look at the development. At some point soon we want
> >> to actually start posting the patches to the mailing list. This is
> >> where it gets tricky.  The code basically not only adds a new driver
> >> but it modifies two existing ones, heavily. To make it more murky one
> >> driver is in staging the other is in the usual drivers/infiniband tree.
> >>
> >> The question is, how do we go about this logistically due to the 2
> >> drivers being in separate sub-trees?
> >>
> >> Greg, Doug,
> >> As the maintainers of the two trees involved we'd kind of like to get
> >> your thoughts on this.
> > 
> > Hi Greg and Doug,
> > 
> > Just wanted to ping you guys again in case my mail last week slipped
> > through the cracks. We are at the point now where we have some patches
> > we can start posting. Looking for some logistical guidance.
> 
> Sorry, I've been out for a while now with the birth of my second child.
>  Things have settled down enough around here that I should be able to
> get things going again (at least well enough to be more responsive to
> email anyway).

Congratulations!

> 
> So, as to the hfi1/qib/rxe transport library.  The qib driver is in the
> rdma tree, and we aren't going to move it to staging just because it
> depends on something in staging, so we need to start adding the library
> in the core tree to avoid dependency issues.  As for the hfi1 driver,
> I'm of the opinion that putting it in staging because of the code
> duplication issue was probably not the right thing to do.  It's
> benefited from the extra eyes on it to help make it a better driver, but
> I think I'm ready to move it to the main RDMA tree and start working on
> it from there where there won't be any cross tree dependency issues.
> 
> To that end, I've opened my 4.4-rc branch and deleted the three
> deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
> sent an email to Linus to see if he's ok taking those changes, and if
> so, I'll get them submitted and then open up my for-4.5 branch early to
> be able to start taking for-next patches.

I agree this is the correct way to go.

However, we have patches which are either in staging-next, staging-testing, or
in flight.

How should we handle those?  I propose.

Greg can ignore the patches in flight.  We have reworks on them anyway.  Those
which just went in to staging-testing can get dropped and we will resubmit
them.

For those which are in staging-next we can submit revert patches to avoid
merge conflicts and resubmit those as well.  This is the item I am not sure
about?

Or is there a better more standard way of handling this?

Ira

Re: HFI1 code duplication todo

[Dan Carpenter]

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> So, as to the hfi1/qib/rxe transport library.  The qib driver is in the
> rdma tree, and we aren't going to move it to staging just because it
> depends on something in staging, so we need to start adding the library
> in the core tree to avoid dependency issues.  As for the hfi1 driver,
> I'm of the opinion that putting it in staging because of the code
> duplication issue was probably not the right thing to do.  It's
> benefited from the extra eyes on it to help make it a better driver, but
> I think I'm ready to move it to the main RDMA tree and start working on
> it from there where there won't be any cross tree dependency issues.

You could leave it staging but manage it from the same git tree.  It
avoids the cross tree dependencies.  This is what we do for
drivers/staging/media/, all that stuff goes through the linux-media
tree.

regards,
dan carpenter

Re: HFI1 code duplication todo

[ira.weiny]

On Sat, Nov 21, 2015 at 01:25:23AM +0300, Dan Carpenter wrote:
> On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> > So, as to the hfi1/qib/rxe transport library.  The qib driver is in the
> > rdma tree, and we aren't going to move it to staging just because it
> > depends on something in staging, so we need to start adding the library
> > in the core tree to avoid dependency issues.  As for the hfi1 driver,
> > I'm of the opinion that putting it in staging because of the code
> > duplication issue was probably not the right thing to do.  It's
> > benefited from the extra eyes on it to help make it a better driver, but
> > I think I'm ready to move it to the main RDMA tree and start working on
> > it from there where there won't be any cross tree dependency issues.
> 
> You could leave it staging but manage it from the same git tree.  It
> avoids the cross tree dependencies.  This is what we do for
> drivers/staging/media/, all that stuff goes through the linux-media
> tree.

My concern is that we tried this before and it did not work.

https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg27842.html
https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg27858.html

Shall we try it again?

Ira

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