S.B. --Liran -----Original Message----- From: Hefty, Sean [mailto:sean.he...@intel.com] Sent: Thursday, June 24, 2010 9:06 PM To: Liran Liss; Roland Dreier; Aleksey Senin Cc: linux-rdma; mo...@voltaire.com; aleks...@voltaire.com; yift...@voltaire.com; Tziporet Koren; al...@voltaire.com Subject: RE: When IBoE will be merged to upstream?
> Regarding GID to Eth mappings, we discussed using the standard > create_ah() Verb for this. > In the kernel, create_ah() will call a generic address resolution > function in the cma. > The returned information will be copied back to user-space in a > device- specific structure (since address handles are device-specific). > > This eliminates adding a new get_eth_l2_addr() ABI call > (device-specific or not). > In fact, this approach eliminates adding new ABIs for any kind of > address translation... > > Does this seem reasonable? The current behavior of ibv_create_ah() requires that the caller provide the L2, and if needed, L3 addressing. Any translation between the L3 and L2 addressing must be done before the call is made. E.g. ibv_create_ah does not use the GID to query the SA to obtain LIDs. Why doesn't IBoE follow this same model? LL: because of the RoCE spec, which states that only GID addressing is used at the Verbs level. The address handle fields are unchanged, and the L2 fields (e.g., lid) are reserved. Note that in Ethernet, you normally don't specify L2 addresses at the transport level (i.e., sockets). Callers can use some out of band mechanism for the mapping, call rdma_resolve_addr, or use some standard networking routine. LL: this would require changes to the Verbs API. rdmacm programs addresses using user-space Verbs, or even just passes the application just address handle attributes... -- 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
