>
> ib_verbs define an *extensive* direct HW access API, which is constantly
> evolving.
This is the problem with verbs...
> You cannot describe the intricate object relations and semantics through an
> API.
> In addition, you can't abstract anything or fix stuff in SW.
> The only way to *truly* know what to expect when performing Verbs calls is to
> check the node type.
How can you say this?
mthca, mlx4, mlx5, and qib all have different sets of functionality... all with the same node type. OPA has the same set as qib... same node type.
>
> ib_verbs was never only an API. It started as the Linux implementation of the
> IBTA standard, with guaranteed semantics and wire protocol.
> Later, the interface was reused to support additional RDMA devices. However,
> you could *always* check the node type if you wanted to, thereby retaining the
> standard guarantees. Win-win situation...
Not true at all. For example, Qib does not support XRC and yet has the same node type as mlx4 (5)...
>
> This is a very strong property; we should not give up on it.
On the contrary the property is weak and implies functionality or lack of functionality rather than being explicit. This was done because getting changes to kernel ABIs was hard and we took a shortcut with node type which we should not have. OPA attempts to stop this madness and supports the functionality of verbs _As_ _Defined_ rather than creating yet another set of things which applications need to check against.
>
> >
> > You're right that apps can be coded to other CA types, like RNICs and
> > USNICs. However, those are all very different from an IB_CA due to
> > limited queue pair types or limited primitives. If OPA had that same
> > limitation then I would agree it needs a different node type.
> >
>
> How do you know that it doesn't?
Up until now you have had to take my word for it. Now that the driver has been posted it should be clear what verbs we support (same as qib).
Ira
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
