> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> > > You are pushing abstraction into provider code instead of handling it in a > generic way. > > No, I am defining an API that *make sense* and doesn't leak useless details. > Of course that doesn't force code duplication or anyhting like that, just > implement it smartly. > > I think mlx made a big mistake returning network_type instead of gid index, > and I don't want to see that error enshrined in our API. > > > The Verbs are a low-level API, that should report exactly what was > > received from the wire. In the RoCEv2 case, it should be the GID/IP > > addresses and the protocol type. The addressing information is not > > intended to be used directly by applications; it is the raw bits that > > were accepted from the wire. > > Low level details isn't what any in kernel consumer needs. Everything in > kernel needs the gid index to determine the namespace, routing and other > details. It is not optional. A common API is thus needed to do this > conversion. The Verbs are not intended only for kernel consumers, but also for the ib_core, cma, etc. For the ib_core, a provider needs to report *all* relevant information that is not visible in the packet payload. The network type is part of this information. The proposed changes are a straightforward extension to the code base, directly follow the specification, and adhere to the RDMA stack design in which IP addressing is handled by the cma. Also, I don't want to do any route resolution on the Rx path. A UD QP completion just reports the details of the packet it received. Conceptually, an incoming packet may not even match an SGID index at all. Maybe, responses should be sent from another device. This should not be decided that the point that a packet was received. > > API-wise, once you get the gid index then it is trivial to make easy > extractors > for everything else. ie for example: > rdma_get_ud_src_sockaddr(gid_index,&addr,wc,grh) > rdma_get_ud_dst_sockaddr(gid_index,&addr,wc,grh) > Nice ideas, but not relevant to completions. The resolved dst address could point to another port or device completely. The proper way to handle remote UD addresses is by rdma_ids that encapsulate address handles and bound devices. > > ib_init_ah_from_wc() and friends is exactly the place that you want to > > create an address handle based on completion and packet fields. > > CMA needs exactly the same logic as well, the fact it doesn't have it is a bug > in this series. > init_ah_from_wc() should include a route lookup, and this will be fixed. > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
