> From: Weiny, Ira [mailto:ira.we...@intel.com]
> > ib_verbs define an *extensive* direct HW access API, which is constantly > > evolving. > > This is the problem with verbs... Huh? It is its strength, if you don't break backward compatibility... > > > 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. > Only that qib is IB, which is fully interoperable with mlx* > > > > 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)... The node type is for guaranteeing semantics and interop for the features that you do implement... > > > > > 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. > I totally agree that we should improve the expressiveness and accuracy of our capabilities; you don't need OPA for this. Unfortunately, it is not always the case. Also, there are behaviors that are not defined by the API, but still rely on the node type. Management applications , for example. --Liran
