Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1711456 > unrolled thread

RE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to reconnect transport

Started byTom Talpey <ttalpey@microsoft.com>
First post2017-08-14 23:10 +0200
Last post2017-08-15 01:40 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  RE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to  reconnect transport Tom Talpey <ttalpey@microsoft.com> - 2017-08-14 23:10 +0200
    RE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to  reconnect transport Long Li <longli@microsoft.com> - 2017-08-15 01:40 +0200

#1711456 — RE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to reconnect transport

FromTom Talpey <ttalpey@microsoft.com>
Date2017-08-14 23:10 +0200
SubjectRE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to reconnect transport
Message-ID<ueuMx-IV-3@gated-at.bofh.it>
> -----Original Message-----
> From: linux-cifs-owner@vger.kernel.org [mailto:linux-cifs-
> owner@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French <sfrench@samba.org>; linux-cifs@vger.kernel.org; samba-
> technical@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: Long Li <longli@microsoft.com>
> Subject: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer to
> reconnect transport
> 
> +int cifs_reconnect_rdma_session(struct TCP_Server_Info *server)
> +{
> +       log_rdma_event("reconnecting rdma session\n");
> +
> +       // why reconnect while it is still connected?
> +       if (server->rdma_ses->transport_status == CIFS_RDMA_CONNECTED) {
> +               log_rdma_event("still connected, not reconnecting\n");
> +               return -EINVAL;
> +       }

Why is this check needed?

> +
> +       // wait until the transport is destroyed
> +       while (server->rdma_ses->transport_status != CIFS_RDMA_DESTROYED)
> +               msleep(1);

Polling!? Please plan to implement a proper handshake for connection logic.

[toc] | [next] | [standalone]


#1711567

FromLong Li <longli@microsoft.com>
Date2017-08-15 01:40 +0200
Message-ID<uex7I-21H-15@gated-at.bofh.it>
In reply to#1711456

> -----Original Message-----
> From: Tom Talpey
> Sent: Monday, August 14, 2017 2:03 PM
> To: Long Li <longli@microsoft.com>; Steve French <sfrench@samba.org>;
> linux-cifs@vger.kernel.org; samba-technical@lists.samba.org; linux-
> kernel@vger.kernel.org
> Subject: RE: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer
> to reconnect transport
> 
> > -----Original Message-----
> > From: linux-cifs-owner@vger.kernel.org [mailto:linux-cifs-
> > owner@vger.kernel.org] On Behalf Of Long Li
> > Sent: Wednesday, August 2, 2017 4:11 PM
> > To: Steve French <sfrench@samba.org>; linux-cifs@vger.kernel.org;
> > samba- technical@lists.samba.org; linux-kernel@vger.kernel.org
> > Cc: Long Li <longli@microsoft.com>
> > Subject: [[PATCH v1] 23/37] [CIFS] SMBD: Implement API for upper layer
> > to reconnect transport
> >
> > +int cifs_reconnect_rdma_session(struct TCP_Server_Info *server) {
> > +       log_rdma_event("reconnecting rdma session\n");
> > +
> > +       // why reconnect while it is still connected?
> > +       if (server->rdma_ses->transport_status == CIFS_RDMA_CONNECTED)
> {
> > +               log_rdma_event("still connected, not reconnecting\n");
> > +               return -EINVAL;
> > +       }
> 
> Why is this check needed?

This was used in early stage of development. It's probably not needed anymore. Will look into this.

> 
> > +
> > +       // wait until the transport is destroyed
> > +       while (server->rdma_ses->transport_status !=
> CIFS_RDMA_DESTROYED)
> > +               msleep(1);
> 
> Polling!? Please plan to implement a proper handshake for connection logic.

Will look into using wait queue.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web