Comparing Busy Poll Socket and NAPI Low response time is the requirement for high performance computing applications. The network latency is an important influence factor on response time. Busy poll socket (BPS) is a new mechanism that can reduce network latency by introducing extra energy cost to busily poll RX queue. Unlike hardware dependent solutions such as RDMA, busy poll socket can improve performance without specialized hardware and transplanting applications. BPS now becomes mature and is supported by many offtheshelf network interface cards. In this paper, we compare the mechanisms of BPS and NAPI. We make a comprehensive analysis about both BPS and NAPI mechanisms. We analyze which factors would influence latencies in BPS and NAPI modes respectively. We find out that BPS does not definitely outperform NAPI, and the reasons are explored in detail. Our findings can provide suggestions on the future deployment of BPS based applications.

Active and Adaptive ApplicationLevel Flow Control for Latency Sensitive RPC Applications The Remote Procedure Call (RPC) frameworks are widely deployed in industry. Applications supported by RPC frameworks are often latencysensitive which strictly require to be responded before the deadline. For meeting this requirement, RPC frameworks adopt the applicationlevel flow control mechanism. This mechanism gives an appropriate threshold determining the number of RPC requests that the server can process, thus avoids missing the deadline. However, this threshold at the applicationlevel is a fixed empirical value so that it is hard to obtain respectable performance because an endpointu0027s processing capacity can take a huge quantity of values by varying workload and different hardware configurations. While other methods based on specialized transport protocols are adaptive, they will introduce extra costs for message reporting from server to client. Furthermore, adopting specialized transport protocols will also introduce extra transplanting efforts for TCPbased applications. In this paper, we provide an active and adaptive application level flow control mechanism at the client side. We first design an algorithm to find the appropriate threshold to achieve the desired response time. Then based on this algorithm, we control the threshold to bound the response time as expected. We implement our flow control mechanism using a memcached testbed. Experiments prove that our mechanism can accurately reduce the mean and 99th percentile response time by at least 71.3% and 69.4% respectively, while keeping a relatively high QPS. Furthermore, compared to staticthreshold mechanism, our flow control mechanism is more efficient under low latency constraints.