Roland Dreier wrote:
Yes, that's right. Something like the patch below (compile tested
only) is what is required.
good. I have committed the patch below and tested it to work fine.
Or.
use device-node_guid instead of device_attr-node_guid to match devices
corresponding to the same IP subnet
Or Just to make sure, would the __be64 node_guid field of struct
Or ib_device have the exact semantics of the __be64 node_guid
Or field of struct ib_device_attr ? iser uses it from the attr
Or struct and we can sure move to use it from the device struct.
Yes, that's right.
Sean Hefty wrote:
I installed git, pulled the latest tree, and am working on a set of
patches for this. I think that a patch series could be broken up as
follows:
Address translation service.
Marshalling parameters between userspace and the kernel.
CM comparing private data.
Kernel CMA.
On Mon, 2006-01-09 at 18:13, Sean Hefty wrote:
Sean Hefty wrote:
I installed git, pulled the latest tree, and am working on a set of
patches for this. I think that a patch series could be broken up as
follows:
Address translation service.
Marshalling parameters between userspace
Hal Rosenstock wrote:
Also, isn't the fib_frontend.c patch needed too ?
It is, but I included that with my patch that adds ib_addr to the infiniband
tree.
- Sean
___
openib-general mailing list
openib-general@openib.org
Sean Roland, could you generate a patch (or push the changes
Sean upstream) for the node_guid that will work with the mthca
Sean version that is upstream?
Yes, I'll push that stuff upstream shortly. I'd like to completely
kill the node_guid field in struct ib_device_attr at the same
Roland Dreier wrote:
Sean Roland, could you generate a patch (or push the changes
Sean upstream) for the node_guid that will work with the mthca
Sean version that is upstream?
Yes, I'll push that stuff upstream shortly. I'd like to completely
kill the node_guid field in struct
Sean Hefty wrote:
Roland Dreier wrote:
Sean Roland, could you generate a patch (or push the changes
Sean upstream) for the node_guid that will work with the mthca
Sean version that is upstream?
Yes, I'll push that stuff upstream shortly. I'd like to completely
kill the node_guid
Sean Roland, I think that we're ready to try to merge the CMA
Sean upstream. I don't believe that any of the kernel ULP
Sean consumers are ready to be merged yet, but we could submit
Sean the userspace CMA support as a consumer of the API.
Sean What is your recommendation on
