> From: Jason Gunthorpe [mailto:[email protected]]
> Look, here is a concrete direction: > > Replace all the crap in > ib_init_ah_from_wc/get_sgid_index_from_eth/rdma_addr_find_dmac_by_ > grh > > with a straightforward > > rdma_dgid_index_from_wc( > const struct ib_qp *qp, > const struct ib_wc *wc, > const struct ib_grh *grh, > u16 *gid_index) > > Sort of function that reads the GRH and wc and returns the unambiguous gid > index that was used to receive that packet on the UD QP. > > The gid cache is not allowed to create an ambiguity the driver cannot resolve. > > That said, I wouldn't object to vendor-specific bits in the wc. Ie if mlx > hardware needs a network_type bit to implement > rdma_find_dgid_index_from_wc, then fine - define a vendor specific place > to put it. In this case rdma_find_dgid_index_from_wc would be a driver call > back, which is fine, and what Caitlin was talking about. > > But, it is not part of our verbs API, and I'd *strongly* encourage other > vendors and future hardware to simply return the gid index that the > hardware matched instead of requiring the software to try and guess after > the fact. > You are pushing abstraction into provider code instead of handling it in a generic way. 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. I don't want to replicate resolution code in every RoCE driver. 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. This is what applications will use (and only if they are interested in generating a response; otherwise this overhead can be skipped). As I said earlier, we can make sure that protocol type information doesn't incur any additional overhead. --Liran -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
