HFI1 code duplication todo

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.

Quoted 16 lines · 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.

Quoted 6 lines

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.

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.

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.

Quoted 5 lines · Doug Ledford

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.

Quoted 7 lines · Greg KH

Quoted 5 lines · Doug Ledford

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 26 lines · Dennis Dalessandro

Quoted 16 lines · 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.

Quoted 6 lines

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,

Quoted 3 lines

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.

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.

Quoted 9 lines · Doug Ledford

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.