Can the channel ID be ignored? [Was Re: af_rxrpc: RXRPC reorganisation]

[Tim Smith]

On Wednesday 28 May 2014 19:53:44 Tim Smith wrote:
> On Wednesday 28 May 2014 11:56:54 David Howells wrote:
> > Tim Smith <tim at electronghost.co.uk> wrote:
> > > struct rxrpc_call seems to contain a lot of stuff which is per-channel
> > 
> > You might also just ignore the channel ID field entirely - except to check
> > that it's correct for any particular call.  We don't really care if we get
> > more than four calls for a connection: the "four channels" thing is there
> > to speed up call lookup - but does it really help with your hashing stuff
> > in place in the kernel?
> 
> You mean just accept the new call anyway? That could be trouble.
> 
> Sending a BUSY when we are in fact busy protects the client's state machine,
> which may reasonably rely on getting that BUSY if its final ACK was eaten
> by Cthulu in the network somewhere.

Or did I get the wrong end of that stick and you meant just search on the full 
content of the ConnectionID field to go straight to the call?

The slight trouble with that is that when a packet comes in for ConnectionID 
0x1b6 (which would mean channel 2), but Call Number 0, that's a connection-
level packet. As I read it a connection-level packet can arrive on any 
channel.

The call processor now has to look outside its context and we're back into 
worrying about locks & concurrency. I'd like to make sure it never has to do 
that if I can, which appears to mean dealing with connection-level packets 
before they get into a call context.


-- 
Tim Smith <tim at electronghost.co.uk>
"I cannot test the USB because the user interface is encrypted."
    -- Hugo Tyson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20140528/7d1f9094/attachment.sig>