Re: [PATCH] support larger cifs network reads

2007-06-05 Thread Christoph Hellwig
On Thu, May 31, 2007 at 06:08:23PM -0500, Steve French wrote:
> With Samba 3.0.26pre it is now possible for a cifs client (one which
> supports the newest Unix/Posix cifs extensions) to request up to
> almost 8MB at a time on a cifs read request.
> 
> A patch for the cifs client to support larger reads follows.  In this
> patch, using very large reads is not the default behavior, since it
> would require larger buffer allocations for the large cifs request
> buffers, but in the future when cifs can demultiplex reads to a page
> list in the cifs_demultiplex_thread (without having to copy to a large
> temporary buffer) this will be even more useful.

Increasing this now doesn't make any sense - slab won't be able to
create a 8MB cache on most architectures, and even if it could the
wasted memory would be enormous.  Once you actually support
scatter/gather allocations an increase is fine.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] support larger cifs network reads

2007-05-31 Thread Steve French

With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.

A patch for the cifs client to support larger reads follows.  In this
patch, using very large reads is not the default behavior, since it
would require larger buffer allocations for the large cifs request
buffers, but in the future when cifs can demultiplex reads to a page
list in the cifs_demultiplex_thread (without having to copy to a large
temporary buffer) this will be even more useful.

diff --git a/fs/cifs/README b/fs/cifs/README
index 4d01697..6ad722b 100644
--- a/fs/cifs/README
+++ b/fs/cifs/README
@@ -301,8 +301,19 @@ A partial list of the supported mount op
during the local client kernel build will be used.
If server does not support Unicode, this parameter is
unused.
-  rsizedefault read size (usually 16K)
-  wsizedefault write size (usually 16K, 32K is often better 
over GigE)
+  rsizedefault read size (usually 16K). The client currently
+   can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
+   defaults to 16K and may be changed (from 8K to the maximum
+   kmalloc size allowed by your kernel) at module install time
+   for cifs.ko. Setting CIFSMaxBufSize to a very large value
+   will cause cifs to use more memory and may reduce performance
+   in some cases.  To use rsize greater than 127K (the original
+   cifs protocol maximum) also requires that the server support
+   a new Unix Capability flag (for very large read) which some
+   newer servers (e.g. Samba 3.0.26 or later) do. rsize can be
+   set from a minimum of 2048 to a maximum of 8388608 (depending
+   on the value of CIFSMaxBufSize)
+  wsizedefault write size (default 57344)
maximum wsize currently allowed by CIFS is 57344 (14 4096 byte
pages)
  rwmount the network share read-write (note that the
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index d38c69b..8c4365d 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -732,10 +732,21 @@ cifs_init_request_bufs(void)
/* Buffer size can not be smaller than 2 * PATH_MAX since maximum
Unicode path name has to fit in any SMB/CIFS path based frames */
CIFSMaxBufSize = 8192;
-   } else if (CIFSMaxBufSize > 1024*127) {
-   CIFSMaxBufSize = 1024 * 127;
} else {
-   CIFSMaxBufSize &= 0x1FE00; /* Round size to even 512 byte mult*/
+   if (CIFSMaxBufSize + MAX_CIFS_HDR_SIZE > KMALLOC_MAX_SIZE) {
+   CIFSMaxBufSize = KMALLOC_MAX_SIZE - MAX_CIFS_HDR_SIZE;
+   cERROR(1,("CIFSMaxBufSize too large, resetting to %ld",
+  KMALLOC_MAX_SIZE));
+   }
+   
+   /* The length field is 3 bytes, but for time being we use only
+*  23 of the available 24 length bits */
+   if (CIFSMaxBufSize > 8388608) {
+   CIFSMaxBufSize = 8388608;
+   cERROR(1,
+   ("CIFSMaxBufSize set to protocol max 8388608"));
+   } else  /* round buffer size to even 512 byte multiple */
+   CIFSMaxBufSize &= 0x7FFE00;
}
/*  cERROR(1,("CIFSMaxBufSize %d 0x%x",CIFSMaxBufSize,CIFSMaxBufSize)); */
cifs_req_cachep = kmem_cache_create("cifs_request",
diff --git a/fs/cifs/cifspdu.h b/fs/cifs/cifspdu.h
index d619ca7..6e6cda0 100644
--- a/fs/cifs/cifspdu.h
+++ b/fs/cifs/cifspdu.h
@@ -1885,15 +1885,19 @@ typedef struct {
#define CIFS_UNIX_POSIX_PATHNAMES_CAP   0x0010 /* Allow POSIX
path chars  */
#define CIFS_UNIX_POSIX_PATH_OPS_CAP0x0020 /* Allow new POSIX
path based
  calls including posix open
- and posix unlink */
+ and posix unlink */
+#define CIFS_UNIX_LARGE_READ_CAP0x0040 /* support reads >128K (up
+ to 0x00 */

+#define CIFS_UNIX_LARGE_WRITE_CAP   0x0080
+
#ifdef CONFIG_CIFS_POSIX
/* Can not set pathnames cap yet until we send new posix create SMB since
   otherwise server can treat such handles opened with older ntcreatex
   (by a new client which knows how to send posix path ops)
   as non-posix handles (can affect write behavior with byte range locks.
   We can add back in POSIX_PATH_OPS cap when Posix Create/Mkdir finished */
-/* #define CIFS_UNIX_CAP_MASK  0x003b */
-#define CIFS_UNIX_CAP_MASK  0x001b
+/* #define CIFS_UNIX_CAP_MASK