Hi folks, The SMB3.0 documentation refers to this model for multiple channels: http://msdn.microsoft.com/en-us/library/cc246488%28v=prot.13%29 This shows multiple sessions, each with a group of channels over multiple connections. The connections are intended, I believe, to be references to TCP connections and RDMACM connections. It seems possible that two sessions to the same server could actually exist over different connections to the same server. Currently, in connect.c:cifs_mount we take a bottom up approach. We search for a TCP session (cifs_get_tcp_session) and as a side effect, return a new TCP connection if we don't find it. Then we search for an SMB session on that connection, and, as a side effect, create a new session if we don't find it. It the multi-connect world, this *seems* wrong. It seems to me that we should search for a TCON first, and if we don't find one, establish a new on. Establishing a new TCON will cause us to search for an existing session that matches the credentials we have in hand (and possibly one matching the transport type or the specific transport we were asked to use), and if we don't find one, we need to create a new session with those credentials. Creating a new session will cause us to search for an existing connection to the server, at which point we might come up with multiple connections, and so we can perhaps use the one with the fewest sessions bound to it or some other heuristic and start the session. We will also then likely engage in multi-connect with one or more of the remaining connections. However, if we do not find any connections of the appropriate type, we will have to create a new connection (and will want to create more connections if multi-connect is supported by the server). So, I am suggesting that the approach we take needs to be re-ordered. Fortunately, I think, it is all confined to cifs_mount. Does anyone have any comments? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
