Currently there is one array of pages that acts as both a receive and send buffer while an nfsd thread executes an RPC. There is a pointer into the array that demarcates where the receive buffer ends and the send buffer begins. This arrangement was set up during the NFSv3 days, where there were no NFS operations that needed more than a megabyte (combined) for the RPC Call and RPC Reply.
With NFSv4 COMPOUNDs, the situation is not as straightforward. A COMPOUND Call that contains many operations can generate a Reply that also has many results. There is no guarantee that the combined XDR buffer will remain within the bounds of rq_pages. Therefore there is a lot of extra logic during COMPOUND processing to ensure that the arguments and results can fit in rq_pages.
Moreover, tracking the boundary between the receive and send buffers is hard to reason about and therefore error prone.
The cost of having two page arrays would be allocating double the number of pages per thread (2MB per thread instead of 1MB in typical configurations).
The benefit would be fewer size constraints during COMPOUND processing, and simpler transport implementations (the transports are generally responsible for determining where the receive buffer ends and the send buffer (the pages remaining in rq-pages) begins.
Currently there is one array of pages that acts as both a receive and send buffer while an nfsd thread executes an RPC. There is a pointer into the array that demarcates where the receive buffer ends and the send buffer begins. This arrangement was set up during the NFSv3 days, where there were no NFS operations that needed more than a megabyte (combined) for the RPC Call and RPC Reply.
With NFSv4 COMPOUNDs, the situation is not as straightforward. A COMPOUND Call that contains many operations can generate a Reply that also has many results. There is no guarantee that the combined XDR buffer will remain within the bounds of rq_pages. Therefore there is a lot of extra logic during COMPOUND processing to ensure that the arguments and results can fit in rq_pages.
Moreover, tracking the boundary between the receive and send buffers is hard to reason about and therefore error prone.
The cost of having two page arrays would be allocating double the number of pages per thread (2MB per thread instead of 1MB in typical configurations).
The benefit would be fewer size constraints during COMPOUND processing, and simpler transport implementations (the transports are generally responsible for determining where the receive buffer ends and the send buffer (the pages remaining in rq-pages) begins.