af_rxrpc: RXRPC reorganisation
tim at electronghost.co.uk
Mon May 26 11:22:04 PDT 2014
I think I need to re-organise a chunk of the RXRPC code...
The race that's happening that's causing the server to send a BUSY is a bit
nastier than I thought. Rather than being a race between the input and the
output, it's a race between inputs.
What's happening is, the final ACKs from the client are getting into the call
work queues and then not getting processed for a while, and the new call
setups are arriving and getting processed first.
struct rxrpc_call seems to contain a lot of stuff which is per-channel (really
it describes a channel), but it gets created anew for each call. I really want
to feed the new call setup to a per-channel work queue, but no such queue
exists at the right time...
So I was thinking of reorganising things as follows:
Each connection has RXRPC_MAXCALLS (practically, 4) pre-allocated channels
which live as long as the connection, and whose state is never modified except
by the workqueue each has for processing packets.
Thus getting a packet into the right queue becomes a pretty simple lookup:
find the connection (instead of the call/channel as at present) using a hash
table, and drop the packet into the correct channel's queue with a straight
array-dereference. Connection-level packets can be dealt with at this time,
but the channel manages its own state machine.
Nothing the channel workqueue does ever modifies any shared state, so no
locking is required (provided everything done by a single workqueue is
strictly ordered - is that true?). If I can guarantee never to destroy a
connection while its channels are active or a local endpoint while its
connections are active, I don't need to hold locks (or even reference
counts?), which means I can cheerfully manage whatever memory I need to
allocate on a per-call basis in the channel worker without needing much in the
way of destructor queues.
This'll be a rather big patch though. You up for a big patch?
Tim Smith <tim at electronghost.co.uk>
"Dude." "Dude." "Dentist." "Dude."
-- Conversation overheard between two eCos hackers
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the linux-afs