> On Jul 23, 2022, at 4:10 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Fri, 2022-07-22 at 17:55 +0000, Chuck Lever III wrote: >> >> >>> On Jul 22, 2022, at 1:53 PM, Trond Myklebust >>> <trondmy@xxxxxxxxxxxxxxx> wrote: >>> >>> On Fri, 2022-07-22 at 13:25 -0400, Chuck Lever wrote: >>>> There is just one unused bit left in rpc_task::tk_flags, and I >>>> will >>>> need two in subsequent patches. Double the width of the field to >>>> accommodate more flag bits. >>> >>> The values 0x8 and 0x40 are both free, so I'm not seeing why this >>> patch >>> is needed at this time. >> >> It's not needed now, but as recently as last year, there were no free >> bits (and I needed them for RPC-with-TLS support at that time). We >> will >> have to widen this field sooner or later. >> >> I don't have a problem dropping this one if you'd rather wait. >> > > I dropped it after applying the other v2 patches. Thanks for applying the others; I'll drop this one from my private tree. > As I said, I don't > see a need for this expansion yet, and if we do at some point run out > of bits, I can see other flags we can drop (RPC_TASK_ROOTCREDS and > RPC_TASK_NULLCREDS being obvious targets) before we need to consider > actually expanding the size of this field. Agreed, expanding the flags field is no longer necessary for RPC-with-TLS, as I've converted it to use the layered connect mechanism you suggested. The flag it waits on now is XPRT_CONNECTED. > In fact, by not expanding it, we can trivially shrink the size of > struct rpc_task by 8 bytes on x86_64 simply by moving the field > tk_rpc_status to eliminate the current 4 byte hole. I've added a patch > to do just that. -- Chuck Lever
