> -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx [mailto:linux-cifs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Long Li > Sent: Wednesday, August 2, 2017 4:11 PM > To: Steve French <sfrench@xxxxxxxxx>; linux-cifs@xxxxxxxxxxxxxxx; samba- > technical@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Cc: Long Li <longli@xxxxxxxxxxxxx> > 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? > + // 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??? > + > + 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? Tom. -- 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
