On Tue, Jan 10, 2023 at 11:11 PM Paulo Alcantara <pc@xxxxxx> wrote: > > Aurélien Aptel <aurelien.aptel@xxxxxxxxx> writes: > > > Hey Shyam, > > > > I remember thinking that channels should be part of the server too > > when I started working on this but switched it up to session as I kept > > working on it and finding it was the right choice. > > I don't remember all the details so my comments will be a bit vague. > > > > On Tue, Jan 10, 2023 at 10:16 AM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > >> 1. > >> The way connections are organized today, the connections of primary > >> channels of sessions can be shared among different sessions and their > >> channels. However, connections to secondary channels are not shared. > >> i.e. created with nosharesock. > >> Is there a reason why we have it that way? > >> We could have a pool of connections for a particular server. When new > >> channels are to be created for a session, we could simply pick > >> connections from this pool. > >> Another approach could be not to share sockets for any of the channels > >> of multichannel mounts. This way, multichannel would implicitly mean > >> nosharesock. Assuming that multichannel is being used for performance > >> reasons, this would actually make a lot of sense. Each channel would > >> create new connection to the server, and take advantage of number of > >> interfaces and RSS capabilities of server interfaces. > >> I'm planning to take the latter approach for now, since it's easier. > >> Please let me know about your opinions on this. > > > > First, in the abstract models, Channels are kept in the Session object. > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/8174c219-2224-4009-b96a-06d84eccb3ae > > > > Channels and sessions are intertwined. Channels signing keys depend on > > the session it is connected to (See "3.2.5.3.1 Handling a New > > Authentication" and "3.2.5.3.3 Handling Session Binding"). > > Think carefully on what should be done on disconnect/reconnect. > > Especially if the channel is shared with multiple sessions. > > > > Problem with the pool approach is mount options might require > > different connections so sharing is not so easy. And reconnecting > > might involve different fallbacks (dfs) for different sessions. > > AFAICT, for a mount with N channels, whether DFS or not, there is a > wrong assumption that after failover, there will be N channels to be > reconnected. > > There might be a case where the administrator disabled multichannel in > server settings, or decreased the number of available adapters, or if > the new DFS target doesn't support multichannel or has fewer channels. > In this case, cifs.ko would have stale channels trying to reconnect > indefinitely. > > Please correct me if I missed something. Hi Paulo, Your analysis is correct. We don't support scaling down the channel count. Again, this was always the case. I did have some changes planned to deal with that scenario too. Haven't managed to implement it though. -- Regards, Shyam
