> To my understanding, our discussion touches two topics. One is > to solve the TCP port space issue, the other is more general, its about > proper integration of offloaded TCP within Linux. So, the second > topic is a generalization of the first. > > Regarding the first topic, what I was about to propose is that the > iWARP kernel driver (software iWARP or RNIC) itself should take care of > port space allocations. Port space maintenance functionality should > be minimized at iWARP CM level. It looks straightforward to me if > during the rdma_connect() call the driver picks a free port using > a socket/bind sequence for its local interface. The same would be possible > for > the passive connection setup, which always involves an rdma_bind_addr() > - we would have to pass the rdma_bind_addr() call down to the driver > and EADDRINUSE would be a reasonable return value. > Here things are getting a little more complicated, if it comes to > INADDR_ANY and port 0 bindings. In private email, Bob Sharp already > suggested it - the iWARP CM would have to pick a port and > try it on all interfaces....maybe by starting with port 0 binding > on one interface and trying to extend with the returned port on > all remaining interfaces. That introduces an unbind() call if things > fail, too. In any case, the rdma_bind_addr() call would create additional > state > at driver level.
I am okay with adding rdma_bind_addr and rdma_unbind_addr calls. I won't speak for Sean and the work that needs to go into the CM. But this will allow all known iWARP implementations to work together. > For softiwarp, during bind() or connect(), a TCP socket would be created > and bound, for an RNIC driver (currently) the same would happen. While with > softiwarp this socket would be used for communication later, the RNIC > driver > would simply have to keep it around until the connection endpoint gets > destroyed > or the port gets unbound. We want to be careful and make sure there is only one iWARP provider per IP address. If softiWARP binds and surfaces another verbs interface on an existing one, this scheme will not work. Chien -- 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
