On Tue, Jul 04, 2023 at 10:45:20AM +1000, NeilBrown wrote: > On Tue, 04 Jul 2023, Chuck Lever wrote: > > From: Chuck Lever <chuck.lever@xxxxxxxxxx> > > > > To get a sense of the average number of transport enqueue operations > > needed to process an incoming RPC message, re-use the "packets" pool > > stat. Track the number of complete RPC messages processed by each > > thread pool. > > If I understand this correctly, then I would say it differently. > > I think there are either zero or one transport enqueue operations for > each incoming RPC message. Is that correct? So the average would be in > (0,1]. > Wouldn't it be more natural to talk about the average number of incoming > RPC messages processed per enqueue operation? This would be typically > be around 1 on a lightly loaded server and would climb up as things get > busy. > > Was there a reason you wrote it the way around that you did? Yes: more than one enqueue is done per incoming RPC. For example, svc_data_ready() enqueues, and so does svc_xprt_receive(). If the RPC requires more than one call to ->recvfrom() to complete the receive operation, each one of those calls does an enqueue.
