> From: Doug Ledford [mailto:dledf...@redhat.com]
> > > > OPA cannot impersonate IB; OPA node and link types have to be > > > > designated as such. In terms of MAD processing flows, both > > > > explicit (as in the handle_opa_smi() call below) and implicit code > > > > paths (which share IB flows - there are several cases) must make > > > > this distinction. > > > > > > As far as in the kernel is concerned, the individual capability bits > > > are much more important. I would actually like to do away with the > > > node_type variable from struct ib_device eventually. As for user > > > space, We agreed on the concept of capability bits for the sake of simplifying code sharing. That is OK. But the node_type stands for more than just an abstract RDMA device: In IB, it designates an instance of an industry-standard, well-defined, device type: it's possible link types, transport, semantics, management, everything. It *should* be exposed to user-space so apps that know and care what they are running on could continue to work. The place for abstraction is in the rdmacm/CMA, which serves applications that just want some RDMA functionality regardless of the underlying technology. > > > > All SMI code has different behavior if it is running on a switch or > > HCA, so testing for 'switchyness' is very appropriate here. > > Sure... > > > cap_is_switch_smi would be a nice refinement to let us drop nodetype. > > Exactly, we need a bit added to the immutable data bits, and a new cap_ > helper, and then nodetype is ready to be retired. Add a bit, drop a > u8 ;-) > This is indeed a viable solution. > > I don't have a problem with sharing the IBA constant names for MAD > > structures (like RDMA_NODE_IB_SWITCH) between IB and OPA code. They > > already share the structure layouts/etc. > > The node type is reflected to user-space, which, as I mentioned above, is important. Abusing this enumeration is misleading, even in the kernel. Jason's proposal for a 'cap_is_switch_smi' is more readable, and directly in line with the explicit capability approach that we discussed.
