On Fri, 2017-04-28 at 12:23 -0700, Chandramouli, Dasaratharaman wrote: > > On 4/28/2017 11:47 AM, Chandramouli, Dasaratharaman wrote: > > > > > > > > On 4/28/2017 11:10 AM, Doug Ledford wrote: > > > > > > On Mon, 2017-03-20 at 19:38 -0400, Dasaratharaman Chandramouli > > > wrote: > > > > > > > > This series moves the classport info query initiation and > > > > update > > > > from callers such as ipoib to the ib_sa module itself. The > > > > classport > > > > info cache is updated whenever ib_sa receives an appropriate > > > > state > > > > change event. > > > > > > > > Since classport info is only used to check if sendonly full > > > > member > > > > support > > > > is enabled by the SM, we expose a function > > > > ib_sa_sendonly_fullmem_support > > > > that can be called to check if the support is enabled. > > > > > > > > Additionally, we introduce support for opa classport info. > > > > These are > > > > defined specifically for OPA devices and expose additional > > > > features > > > > in the > > > > capability mask bits along with longer LID sizes in some of the > > > > other > > > > fields. > > > > > > > > Patch 1 to 3 fix checkpatch issues (1 issue type per patch) on > > > > two > > > > functions that patch 4 then moves around. Patch 5 makes changes > > > > to implicitly query and cache classport info. Patch 6 adds > > > > verbs capability API for core layers to query and find out if > > > > they > > > > are running on an OPA device. Finally, patch 7 adds OPA > > > > classport > > > > info > > > > query support. > > > > > > I took patches 1-6 of this series. However, I need you to rebase > > > patch > > > 7 against my current k.o/for-4.12-rdma-netdevice branch as there > > > are > > > significant conflicts between this and the VNIC patches I've > > > already > > > taken. > > > > > > > Hi Doug -- I pulled your for-4.12-rdma-netdevice and tried to apply > > patch 7. I see no conflicts. It compiled cleanly as well. May be i > > am > > missing something here. Just want to make sure i have the same > > branch as > > yours. > > Is this your commit at the HEAD currently? > > > > commit 94d595c56077fd8b0f61701e03fd4b3dc8c62038 > > Author: Dasaratharaman Chandramouli <dasaratharaman.chandramouli@in > > tel.com> > > Date: Mon Mar 20 19:38:09 2017 -0400 > > > > IB/core: Add rdma_cap_opa_ah to expose opa address handles > > > > > > Thanks, > > Dasa > > I take that back. It does fail to compile when OPA_VNIC is enabled > since > struct opa_class_port_info is defined at multiple locations. I will > re-spin this series and in lieu of patch 7, i will submit two > patches, > the first one would cleanup some of the re-defined structure > definitions > and the next one would add SA support for OPA class port info. If it were just a matter of removing the duplicate definition in the vnic driver, I would have done that myself (and in fact I *did* do that myself and then reverted the patches when the compile problems were considerably more complex than that). The vnic driver and this obviously touch some of the same things. Since the vnic driver has been accepted, this patchset needs to treat it as something that must be maintained. Breaking the vnic driver with this patchset is not an option, it's a regression. Go back to the drawing board, don't respin the entire series since I've already taken the first 6 patches, and this time don't post the remainder of the patches until the build actually works! > Once this series is accepted, as cleanup, we can look into fixing > opa_vnic and hfi1 to use the SA to query for OPA classport info. No, do this series right. Make it fix things up as it goes along. And make sure it builds! Also, your other two series are on hold until this gets sorted out. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
