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

[Liu Yuan]

On 07/16/2012 04:38 PM, Christoph Hellwig wrote:
>> Well, so in your proposal, per connection we have 2
>> > threads(rx/tx),right?
> In the original one, yes.  The other option is to use a fixed number
> of RX/TX threads and just hash the connections onto them.  Given that
> the RX/TX threads only do non-blocking I/O in theory one per CPU should
> actually be enough.
> 

The connection management adds the complexity. And the benefit we gain
from it might not be worthy of this complexity.

>> > Still too many connections. Yes, we can avoid
>> > context switches, but I suspect that context switches doesn't count much
>> > because we'll do a disk IO in a perspective of one request. To
>> > conclusion, I think we can afford 2 more context switches. (We can
>> > optimize this by redesign thread implementation later)
> My other problem with excessive workqueue use is that it makes debugging
> code flows pretty hard.
> 

Why is harder than before?

For now, the real problem is that dynamic can't work with tracer code. I
think my proposal is simplest one to overlap requests, also using single
epoll() to manage all the fds looks neat.

We can still avoid most of context switches if we implement a dynamic
grow/shrink threads pool which looks to be a fixed threads pool from
outside.

Thanks,
Yuan