Messages in this thread |  | | From | Long Li <> | Subject | RE: [[PATCH v1] 21/37] [CIFS] SMBD: Implement API for upper layer to receive data | Date | Mon, 14 Aug 2017 23:24:31 +0000 |
| |
> -----Original Message----- > From: Tom Talpey > Sent: Monday, August 14, 2017 1:57 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] 21/37] [CIFS] SMBD: Implement API for upper layer > to receive data > > > -----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] 21/37] [CIFS] SMBD: Implement API for upper layer > > to receive data > > > > /* > > + * Read data from receive reassembly queue > > + * All the incoming data packets are placed in reassembly queue > > + * buf: the buffer to read data into > > + * size: the length of data to read > > + * return value: actual data read > > + */ > > +int cifs_rdma_read(struct cifs_rdma_info *info, char *buf, unsigned > > +int size) { > >... > > + spin_lock_irqsave(&info->reassembly_queue_lock, flags); > > + log_cifs_read("size=%d info->reassembly_data_length=%d\n", size, > > + atomic_read(&info->reassembly_data_length)); > > + if (atomic_read(&info->reassembly_data_length) >= size) { > > If the reassembly queue is protected by a lock, why is an atomic_read() of its > length needed?
Will change this to non-atomic.
> > > + // this is for reading rfc1002 length > > + if (response->first_segment && size==4) { > > + unsigned int rfc1002_len = > > + data_length + remaining_data_length; > > + *((__be32*)buf) = cpu_to_be32(rfc1002_len); > > + data_read = 4; > > + response->first_segment = false; > > + log_cifs_read("returning rfc1002 length %d\n", > > + rfc1002_len); > > + goto read_rfc1002_done; > > + } > > I am totally confused. What does RFC1002 framing have to do with receiving > an SMB Direct packet???
The upper layer expects RFC1002 length at the beginning of the payload. A lot of protocol processing logic check and act on this value. Returning this value will avoid changes to lots of other upper layer code.
This will be eventually fixed when a transport layer is added to upper layer code. I recommend we do it in another patch.
> > > + > > + to_copy = min_t(int, data_length - offset, to_read); > > + memcpy( > > + buf + data_read, > > + (char*)data_transfer + data_offset + offset, > > + to_copy); > > Is it really necessary to perform all these data copies, especially under the > reassembly_queue spinlock? This seems quite inefficient. Can the receive > buffers not be loaned out and chained logically?
This will require upper layer code changes to move to use new buffers allocated/loaned this way, and also deal with packet boundaries.
This code is not used to actually carry file data, which are normally done through RDMA read/write.
If we want to do it, I suggest do another patch since more changes other than transport are involved.
> > Tom.
|  |