SMB2 performance is worse than SMB1 while iometer 512byte transfer

[Jeremy Allison]

On Thu, Sep 12, 2013 at 09:37:47PM +0800, Jones wrote:
> 
> Thanks for the review.
> But I still do not get it why the allocate/free APIs would be put inside
> the loop,
> it seems that every loop is involved memory allocation/reclaim,
> should this behavior be considered as overhead? Or this is just my paranoid.

The reason for this is that it's much easier to prevent
memory leaks by allocating the space for the incoming
packet on receipt - keeping it (and all talloc children)
around whilst the packet is being processed, and then
finally talloc_free'ing the incoming packet and all its
children after the reply has been sent to the client.

That is the reason behind this code:

        while (True) {
                frame = talloc_stackframe_pool(8192);

                errno = 0;
                if (tevent_loop_once(ev_ctx) == -1) {
                        if (errno != EINTR) {
                                DEBUG(3, ("tevent_loop_once failed: %s,"
                                          " exiting\n", strerror(errno) ));
                                break;
                        }
                }

                TALLOC_FREE(frame);
        }

which is the main async loop inside of smbd. Without
something like this it's really easy to get memory
leaks happening. The goal is that all temporary
memory is talloc'ed from the 'frame' stackframe.

> And another thought grows up in my mind these days,
> is SMB2 in samba not  designed for or suitable for small-block transfers,
> so Im too hair-splitting to tune the SMB2 for small-block transfers?

SMB2 is better for large block transfers (SMB2 limits
are usually 1MB reads or writes). Using it for 512 byte
blocks is going to be much less efficient (and is not
what Windows clients do in the real world).

However, this is a really useful excercise to stress
parts of the code and compare between SMB1 and SMB2
handling, so I think it's certainly worthwhile to
identify bottlenecks we can improve (although I wouldn't
expect to see these in real client environments).

Cheers,

	Jeremy.