Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752831AbdHNXYf (ORCPT ); Mon, 14 Aug 2017 19:24:35 -0400 Received: from mail-sn1nam02on0130.outbound.protection.outlook.com ([104.47.36.130]:55468 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752643AbdHNXYd (ORCPT ); Mon, 14 Aug 2017 19:24:33 -0400 From: Long Li To: Tom Talpey , Steve French , "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 Thread-Topic: [[PATCH v1] 21/37] [CIFS] SMBD: Implement API for upper layer to receive data Thread-Index: AQHTC8uqK5f956yfCkW0kL2NPMaDOKKEaDMAgAAmJ+A= Date: Mon, 14 Aug 2017 23:24:31 +0000 Message-ID: References: <1501704648-20159-1-git-send-email-longli@exchange.microsoft.com> <1501704648-20159-22-git-send-email-longli@exchange.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=longli@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-08-14T16:24:30.0713521-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:2::735] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY4PR21MB0503;6:GznBwIBYqPoU6UQr+iDat/VXz6DM3QnTYsTsDxfgb0IPMKRSGRcQ8WRK44+TQI7c0urcXRlwV1VPZx+M5GEbuDIm3EGG8vhJQ1Cpa7+Tjew6+DLZY/OZGl9MiPz2YICMbkG7LZbV5bIyc5SE5V+VMniGDiHMM/qAp3uAdSCb04ci450JHH8ljiEpuR9hLy3c4v2JU1kuqv0LxI7SKe//QylwpKXo1ZIMVz+JkfO5ibNEb5584XX+uOzyXxXPOCRTt2lqAI/a6EFuLkNmgj7kxPWMURu474DdDOqAym6MOrIUNed3aZlgaS1oajlDaKkBGeGA5wTDq32QPtNrT14okw==;5:qmfYq09r+vheuDTJd25ki+RjBhtz+9+lu9Fj/IEuuQAVCReZx768IXsXGQTRMdbxTSU9q3lT4EVBVlgKbWmVIa3yvq5llBd9IfVHMhhos24XMw85eN5mtPp5vR02ZEdptaksW3ZO9uWUZWYw0myc1A==;24:TDakQEiuJuYy4Mcc/y9jhEtO0MyujtLJvU34J/tpJgMZjQPos3tx8kI85qwAG0d1xDcNG0DbGNhinRBCIwcqHul8zNoCpRRheIXkVXLowVg=;7:ARRen5TA6ulMWvXR8FvgJWwMwHGT7zQbhTQBH3aQEC/3pMYZYdE2EpdsLVZsNsAOlpOVCBWN9I1bjhiYZp4rxvwbhFPLPbSvZvJoos7VF3eCsEZQYAzypwmv8BaCB1w7I/9bWZYTwj987vNfmAe8tLTIlXwOUPtZmmyVNUSpbbj9O6q1KrEwBgD6rjrZHlyYNEGmccmZMlnTWqdNUP6Ubt+DEeGME3+K5Ktn9oNVUNg= x-ms-office365-filtering-correlation-id: 63e79acb-82fd-4f68-d959-08d4e36b9e0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603143)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY4PR21MB0503; x-ms-traffictypediagnostic: CY4PR21MB0503: x-exchange-antispam-report-test: UriScan:(89211679590171)(9452136761055); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY4PR21MB0503;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY4PR21MB0503; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(6009001)(39860400002)(47760400005)(377454003)(13464003)(189002)(199003)(25786009)(81156014)(1511001)(8936002)(81166006)(86612001)(74316002)(53936002)(2906002)(5005710100001)(86362001)(8990500004)(14454004)(2501003)(189998001)(2201001)(305945005)(2950100002)(6506006)(77096006)(7736002)(6246003)(229853002)(33656002)(2421001)(478600001)(10290500003)(6436002)(102836003)(6116002)(8676002)(2900100001)(97736004)(101416001)(3660700001)(3280700002)(5660300001)(53546010)(68736007)(7696004)(50986999)(10090500001)(76176999)(54356999)(2561002)(9686003)(55016002)(106356001)(105586002)(99286003)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY4PR21MB0503;H:CY4PR21MB0182.namprd21.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; authentication-results: spf=none (sender IP is ) smtp.mailfrom=longli@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 23:24:31.7480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v7ENOfXi010599 Content-Length: 3606 Lines: 81 > -----Original Message----- > From: Tom Talpey > Sent: Monday, August 14, 2017 1:57 PM > To: Long Li ; Steve French ; > 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 ; linux-cifs@vger.kernel.org; > > samba- technical@lists.samba.org; linux-kernel@vger.kernel.org > > Cc: Long Li > > 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.