Ashish Sangwan

> If we continue to read from a single socket, this breaks this fairness guarantee That is correct. That is why I have added this as conf param. Old behaviour...

One thing we can do is return the number of executing + pending request to the caller of work_pool_submit() i.e. svc_vc_recv(). Based on that, we can decide should we continue...

Thanks @mattbenjamin for the reply. Would you please suggest in your opinion what could be a fair default value? Also, I would like to know your thoughts about returning pending...

Here's a quick summary of the performance numbers I got on my setup with different values of cont_recv_limit cont_recv_limit:SeqThroughput 0:740MB/sec 4:788MB/sec 8:800MB/sec 16:820MB/sec 24:840MB/sec 1000:900MB/sec As next step I will...

>Also of interest though, is affect on concurrent clients. @mattbenjamin I think that once we take the number of pending requests into account, than it will be like old behaviour...

@dang Ok, I am going to measure the directory listing time (in next week or so) for a directory with 100K entries while 0, 2, 4, 6 clients doing parallel...