On Tue, Nov 24, 2015 at 03:47:51PM +0200, Matan Barak wrote: > > It isn't just the hop limit that has to come from the route entry, all > > the source information of the path comes from there. Ie the gid table > > should accept the route entry directly and spit out the sgid_index. > > > > The responder side is the same, it also needs to do a route lookup to > > figure out what it is doing, and that may not match what the rx says > > from the headers. This is important stuff. > > > > The only entity that translates between IPs and GIDs is the RDMACM. The rocev2 stuff is using IP, and the gid entry is now overloaded to specify IP header fields. Absolutely every determination of IP header fields needs to go through the route table, so every single lookup that can return a rocev2 SGID *MUST* use route data. The places in this series where that isn't done are plain and simply wrong. The abstraction at the gid cache is making it too easy to make this mistake. It is enabling callers to do direct gid lookups without a route lookup, which is unconditionally wrong. Every call site into the gid cache I looked at appears to have this problem. The simplest fix is to have a new gid cache api for rocve2 that somehow forces/includes the necessary route lookup. The existing API cannot simply be extended for rocev2. > roce_gid_mgmt, is the part that populates this "dumb" database. > IMHO, adding such a "smart" layer to the GID cache is wrong, as this > should be part of RDMACM which does the translation. No need to get > the gid cache involved. OK. Change the gid cache so only a RDMA CM private API can return rocev2 gids. 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
