> > On 11/13/2014 9:54 PM, [email protected] wrote: > > > Add a device capability flag for OPA devices to signal their support of > > "jumbo" > > MADs. > > > > Check for IB_DEVICE_JUMBO_MAD_SUPPORT in the device capabilities and > > if supported mark the special QPs created. > > Ira, > > Few comments here, the device capability is OK, specifically if it helps for > the > mad layer logic to be simpler and/or more robust. > > You should add device attribute telling what is the size of MADs supported by > the device, I think the IBTA mandated 256Band in the OPA case, the driver will > fill there 2k.
I don't think this is a bad idea, however, the complication is determining the kmem_cache object size in that case. How about we limit this value to < 2K until such time as there is a need for larger support? > > You can't just state that (jumbo == 2k) and go to complete design/changes > which use this hard-coded assumption. You need to see how to re-spin this > series w.o this assumption. I'm looking into it. I believe I will still need to have a capability bit, but it may end up having a different meaning. > > I find it very annoying that upper level drivers replicate in different ways > elements from the IB device attributes returned by ib_query_device. I met that > in multiple drivers and upcoming designs for which I do code review. Are you > up to come up with a patch that caches the device attributes on the device > structure? I don't follow what you are asking for. Could you give more details? > if not, > I can do that.. and have your code to see it. > > Also, I would go and unify (squash) this patch and the preceding one. > I'll keep this in mind as I rework the patches. Ira -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
