On Tue, 04 Jul 2023, Chuck Lever wrote: > 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. > Ahhhh - that makes sense. Thanks. So its really that a number of transport enqueue operations are needed to *receive* the message. Once it is received, it is then processed with no more enqueuing. I was partly thrown by the fact that the series is mostly about the queue of threads, but this is about the queue of transports. I guess the more times a transport if queued, the more times a thread needs to be woken? Thanks, NeilBrown
