[Patch v3 02/19] CIFS: SMBD: Add SMBDirect protocol and transport constants

[Pavel Shilovsky]

2017-08-29 16:00 GMT-07:00 Long Li <longli at microsoft.com>:
>> -----Original Message-----
>> From: Pavel Shilovsky [mailto:piastryyy at gmail.com]
>> Sent: Tuesday, August 29, 2017 3:45 PM
>> To: Long Li <longli at microsoft.com>
>> Cc: Steve French <sfrench at samba.org>; linux-cifs <linux-
>> cifs at vger.kernel.org>; samba-technical <samba-technical at lists.samba.org>;
>> Kernel Mailing List <linux-kernel at vger.kernel.org>; linux-
>> rdma at vger.kernel.org; Christoph Hellwig <hch at infradead.org>; Tom Talpey
>> <ttalpey at microsoft.com>; Matthew Wilcox <mawilcox at microsoft.com>;
>> Long Li <longli at microsoft.com>
>> Subject: Re: [Patch v3 02/19] CIFS: SMBD: Add SMBDirect protocol and
>> transport constants
>>
>> 2017-08-29 12:28 GMT-07:00 Long Li <longli at exchange.microsoft.com>:
>> > From: Long Li <longli at microsoft.com>
>> >
>> > To prepare for protocol implementation, add constants and
>> > user-configurable values in the SMBDirect protocol.
>> >
>> > Signed-off-by: Long Li <longli at microsoft.com>
>> > ---
>> >  fs/cifs/smbdirect.c | 78
>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >  fs/cifs/smbdirect.h | 20 ++++++++++++++
>> >  2 files changed, 98 insertions(+)
>> >  create mode 100644 fs/cifs/smbdirect.c  create mode 100644
>> > fs/cifs/smbdirect.h
>> >
>> > diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c new file mode
>> > 100644 index 0000000..d785bc1
>> > --- /dev/null
>> > +++ b/fs/cifs/smbdirect.c
>> > @@ -0,0 +1,78 @@
>> > +/*
>> > + *   Copyright (C) 2017, Microsoft Corporation.
>> > + *
>> > + *   Author(s): Long Li <longli at microsoft.com>
>> > + *
>> > + *   This program is free software;  you can redistribute it and/or modify
>> > + *   it under the terms of the GNU General Public License as published by
>> > + *   the Free Software Foundation; either version 2 of the License, or
>> > + *   (at your option) any later version.
>> > + *
>> > + *   This program is distributed in the hope that it will be useful,
>> > + *   but WITHOUT ANY WARRANTY;  without even the implied warranty of
>> > + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
>> > + *   the GNU General Public License for more details.
>> > + */
>> > +#include <linux/module.h>
>> > +#include "smbdirect.h"
>> > +#include "cifs_debug.h"
>> > +
>> > +/* SMBD version number */
>> > +#define SMBD_V1        0x0100
>> > +
>> > +/* Port numbers for SMBD transport */
>> > +#define SMB_PORT       445
>> > +#define SMBD_PORT      5445
>> > +
>> > +/* Address lookup and resolve timeout in ms */
>> > +#define RDMA_RESOLVE_TIMEOUT   5000
>> > +
>> > +/* SMBD negotiation timeout in seconds */ #define
>> > +SMBD_NEGOTIATE_TIMEOUT 120
>> > +
>> > +/* SMBD minimum receive size and fragmented sized defined in [MS-
>> SMBD] */
>> > +#define SMBD_MIN_RECEIVE_SIZE          128
>> > +#define SMBD_MIN_FRAGMENTED_SIZE       131072
>> > +
>> > +/*
>> > + * Default maximum number of RDMA read/write outstanding on this
>> > +connection
>> > + * This value is possibly decreased during QP creation on hardware
>> > +limit  */
>> > +#define SMBD_CM_RESPONDER_RESOURCES    32
>> > +
>> > +/* Maximum number of retries on data transfer operations */
>> > +#define SMBD_CM_RETRY                  6
>> > +/* No need to retry on Receiver Not Ready since SMBD manages credits
>> */
>> > +#define SMBD_CM_RNR_RETRY              0
>> > +
>> > +/*
>> > + * User configurable initial values per SMBD transport connection
>> > + * as defined in [MS-SMBD] 3.1.1.1
>> > + * Those may change after a SMBD negotiation  */
>>
>> Since these value are per transport connection, why they are global?
>> Shouldn't they be inside a some structure that is created for a particular
>> connection? Also the constants below should be defines.
>
> Those are configurable initial values (default values) for all connections.
>
> Each connection has its own values based on those initial values. But connection-based values can change after negotiation is done, or after RDMA hardware capabilities are probed.

If these are configurable values, let's add a way to actually
configure them. Through /proc?

--
Best regards,
Pavel Shilovsky