> >> "...A verbs consumer using a RoCE network relies strictly > >> > on so-called > >> > > Layer 3 addressing (GIDs); layer 2 addresses (e.g. subnet local > >> > > identifiers) are not passed across the verbs interface..." > >> > > >> > Ah, hmm, well, I was on that list during this time and I don't > >> think > >> > this statement means what you are saying it does :) > >> > > > > ?? It doesn't get any clearer than this. > > 'subnet local identidifer' == LID > > The text is saying that the specification does not use any of the LID > fields in the verbs interface, that is it. It isn't talking about MAC > addresses. > > Exactly how and where the MAC address comes about was never decided, > and at least some participants thought it should be a 1:1 algorithmic > mapping from the GID. > > Ditto for VLANs, how and where the vlan tag comes about is not part of > the spec. >
You are trying to rewrite history. Read the spec, address handles fields are fixed. > > Good idea! This is exactly what we do today for addresses that the > > user explicitly declares as link-local addresses. But, we can't > > mandate an overload of the GID in a way that it prevents its use as > > a true L3 address (eventually routable). > > We are very unlikely to see routable IBoE, ever.. Says who? > But, even if we do get there some day then we could extend the AH. This is unacceptable - we are not going to add another L3 identifier. > BTW, I absolutely hate the mixing of 'Sometimes it is a IPv4, > sometimes it is a GID, and sometimes it is an IPv6' in the same > field. That is just so nasty. The GID is a GID, don't overload it in > an ambiguous way to mean 2 other things! A GID is a GID indeed -- in a RoCE environment, it's the layer 3 identifier. All of our intended values are standard ipv6 encapsulations. > > > create_ah does not accept any sort of source address > > > specifier > > > > You are wrong -- sgid_index specifies it. > > So, what do you propose to put in sgid_index? It isn't big enough to > store an IPv6 address. You can't exactly number every IP assigned to > every ethernet interface. An iboe device is associated with a specific Ethernet interface. Thus, its gid table only needs to map the ip addresses assigned to that interface. > The other fields you mention are not a supserset of socket parameters, > they are only IPv6 parameters, IPv4 uses a different set. Like what? > > Jason, bottom line, I think that we both agree that the rdmacm > > should do the address resolution. The difference is that by having > > the rdmacm initially only bind to the device and complete the > > resolution later (by a call from create_ah()), we don't change the > > user API for *all* gid types. Having addressed your concerns > > regarding resolution below the Verbs, we continue to believe that > > this is the best approach. > > Again, I don't see how what I've outlined changes the API in any > way. We currently support link-local gids, but the architecture must not limit the scope. > > Doing two routing lookups for the same connection is bad design, it is > racey. L2 parameters have to flow from the first routing lookup in > RDMA-CM to everything else. > So is caching L3-->L2 mappings that change a second later... So what? > Liran, I don't think you have at all come close to addressing my > concerns, you still haven't explained how a full route lookup is even > possible in create_ah, for instance. Let alone my other concerns! > > Jason > -- 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
