Hi Pavel, Thanks for the review. As Tom pointed out, the server name is currently a field in TCP_Session_Info struct. We do store the struct sockaddr_storage, which I'm guessing holds the IP address in binary format, and we could use that. And may need to consider IPv4 vs IPv6 when we do it. I'll submit that as a new patch later on. Hi Tom, > Including the transport type (TCP, RDMA...) and multichannel attributes > (link speed, RSS count, ...) would be useful too. Can you please clarify this for me? >From what I can see from the code, RDMA connection DebugData is a superset of TCP connection. The RDMA specific details get printed only when server->rdma is set. Regards, Shyam On Thu, Feb 11, 2021 at 11:41 AM Tom Talpey <tom@xxxxxxxxxx> wrote: > > On 2/11/2021 12:12 PM, Pavel Shilovsky wrote: > > Hi Shyam, > > > > The output looks very informative! I have one comment: > > > > Servers: > > 1) ConnectionId: 0x1 > > Number of credits: 326 Dialect 0x311 > > TCP status: 1 Instance: 1 > > Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 > > In Send: 0 In MaxReq Wait: 0 > > > > Sessions: > > 1) Name: 10.229.158.38 Uses: 1 Capability: 0x300077 Session Status: 1 > > ^^^^ > > Isn't this name (or hostname) a property of the connection? I would > > expect an IP or a hostname to be printed in the connection settings > > above. > > The servername is a property of the session, in this case since the > mount specified a dotted quad, it would correctly appear as the > servername at this level. > > However, I definitely agree that an IP address is important in the > per-connection (channel) stanzas. Multichannel, multihoming, witness > redirects, and any number of things can vary among them. It would > be useful indeed to display them. > > Including the transport type (TCP, RDMA...) and multichannel attributes > (link speed, RSS count, ...) would be useful too. > > Tom. > > > > > -- > > Best regards, > > Pavel Shilovsky > > > > чт, 11 февр. 2021 г. в 06:24, Aurélien Aptel <aaptel@xxxxxxxx>: > >> > >> Shyam Prasad N <nspmangalore@xxxxxxxxx> writes: > >>> I noticed that the output looks rather odd when used with multichannel. > >>> Attaching a revised patch with the changes. > >>> > >>> Also attached a sample of new output. > >> > >> Reviewed-by: Aurelien Aptel <aaptel@xxxxxxxx> > >> > >> -- > >> Aurélien Aptel / SUSE Labs Samba Team > >> GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > >> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > >> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > >> > > -- Regards, Shyam
