On Sun, Dec 13, 2015 at 3:56 PM, Liran Liss <liranl@xxxxxxxxxxxx> wrote: >> From: linux-rdma-owner@xxxxxxxxxxxxxxx [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. > This was already fixed in v2. >> Jason >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the >> body of a message to majordomo@xxxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
