> From: Doug Ledford [mailto:dledford@xxxxxxxxxx] > > 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. > > I'm sorry, but your argument here is not very convincing at all. And > it's somewhat hypocritical. When RoCE was first introduced, the *exact* > same argument could be used to argue for why RoCE should require a new > node_type. Except then, because RoCE was your own, you argued for, and > got, an expansion of the IB node_type definition that now included a > relevant link_layer attribute that apps never needed to care about > before. However, now you are a victim of your own success. You set the > standard then that if the new device can properly emulate an IB Verbs/IB > Link Layer device in terms of A) supported primitives (iWARP and usNIC > both fail here, and hence why they have their own node_types) and B) > queue pair creation process modulo link layer specific addressing > attributes, then that device qualifies to use the IB_CA node_type and > merely needs only a link_layer attribute to differentiate it. > No. RoCE is as an open standard from the IBTA with the exact same RDMA protocol semantics as InfiniBand and a clear set of compliancy rules without which an implementation can't claim to be such. A RoCE device *is* an IB CA with an Ethernet link. In contrast, OPA is a proprietary protocol. We don't know what primitives are supported, and whether the semantics of supported primitives are the same as in InfiniBand. > The new OPA stuff appears to be following *exactly* the same development > model/path that RoCE did. When RoCE was introduced, all the apps that > really cared about low level addressing on the link layer had to be > modified to encompass the new link type. This is simply link_layer > number three for apps to care about. > You are missing my point. API transparency is not a synonym for full semantic equivalence. The Node Type doesn’t indicate level of adherence to an API. Node Type indicates compliancy to a specification (e.g. wire protocol, remote order of execution, error semantics, architectural limitations, etc). The IBTA CA and Switch Node Types belong to devices that are compliant to the corresponding specifications from the InfiniBand Trade Association. And that doesn’t prevent applications to choose to be coded to run over nodes of different Node Type as it happens today with IB/RoCE and iWARP. This has nothing to do with addressing. ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
