[sheepdog] [RFC PATCH] sdnet: threading tx/rx process

[Christoph Hellwig]

On Thu, Jul 12, 2012 at 03:20:29PM +0800, Liu Yuan wrote:
> On 07/12/2012 02:18 PM, HaiTing Yao wrote:
> > 1,  Can not guarantee I/O sequence of VDI. Many tx/rx threads, many io
> > threds. If two requests r/w the same sector of same VDI, data will be
> > corrupted.
> > 
> 
> I think we will never get two requests R/W the same sector, because VM's
> kernel should(might) guarantee this, at least for linux.

At least Windows does not, we had a problem in qemu with this before,
note that even in this case there is no ordering guarantee so I don't
think it actually is a problem.

> > 2,  I did not test the performance of this patch, but I think it will
> > not be better than before. The time for creating/destroing threads may
> > be longer than the time for data translation.
> 
> Yes, short threads for this tx/rx would be the performance bottleneck. I
> benchmark the write performance with my patch, seems that no noticeable
> boost.

I really don't like either implementation.  For one I'd really love to
figure out the root cause, that is where we spend all that time doing
epoll driven non-blocking I/O.  Second if we go for a more threaded
network I/O model I'd like to design it based on possible contention
points, and avoiding creating threads all the time, which leads to a
per-connection thread model where listen_handler creates a RX and a TX
thread per connection which then uses EPOLL to handle all I/O on it.