On Tue, Oct 13, 2015 at 7:18 PM, Hefty, Sean <sean.hefty@xxxxxxxxx> wrote: >> On Mon, Oct 12, 2015 at 7:42 PM, Hefty, Sean <sean.hefty@xxxxxxxxx> wrote: >> >> When IP based addressing was introduced, ib_create_ah_from_wc was >> >> changed in order to support a suitable AH. Since this AH should >> >> now contains the DMAC (which isn't a simple derivative of the GID). >> >> In order to find the DMAC, an ARP should sometime be sent. This ARP >> >> is a sleeping context. >> > >> > Wait - are you saying that the CM may now be waiting for an ARP response >> before it can send a message? >> > >> >> ib_create_ah_from_wc needs to resolve the DMAC in order to create the >> AH (this may result sending an ARP and waiting for response). >> CM uses this function (which is now sleepable). > > This is a significant change to the CM. The CM calls are invoked assuming that they return relatively quickly. They're invoked from callbacks and internally. Having the calls now wait for an ARP response requires that this be re-architected, so the calling thread doesn't go out to lunch for several seconds. Agree - this is a significant change, but it was done a long time ago (at v4.3 if I recall). When we need to send a message we need to figure out the destination MAC. Even the passive side needs to do that as some vendors don't report the source MAC of the packet in their wc. Even if they did, since IP based addressing is rout-able by its nature, it should follow the networking stack rules. Some crazy configurations could force sending responses to packets that came from router1 to router2 - so we have no choice than resolving the DMAC at every side. > > - Sean Matan -- 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
