[PATCH] af_rxrpc: Keep rxrpc_call pointers in a hashtable

[Tim Smith]

On Friday 14 February 2014 02:34:42 David Howells wrote:
> Tim Smith <tim at electronghost.co.uk> wrote:
> > Keep track of rxrpc_call structures in a hashtable so they can be
> > found directly from the network parameters which define the call.
> 
> Just a few quick thoughts.
> 
> > +	const u8	*peer_addr)
> > +{
> > +	const u8 *p;
> 
> You can probably get away with using u16 instead, at least for p.  The
> alignment should work.  You would need to fold the result though.
> 
> > +	uintptr_t key = 0;
>
> I recommend using unsigned long type.

Really? OK. It's an unsigned integer of the right size to hold a pointer on 
the current architecture because I'm dumping a pointer into it. I don't 
suppose it really matters for this purpose though.

 
> > +	key += (cid & RXRPC_CIDMASK) >> RXRPC_CIDSHIFT;
> > +	key += cid & RXRPC_CHANNELMASK;
> 
> cid is __be32 not machine endian so this won't work.

Point.

> You may want to fold key down to a 16-bit integer before taking the modulus.
> > +	key = rxrpc_call_hashfunc(call->in_clientflag, call->cid,
> > +				  call->call_id, call->epoch,
> > +				  call->service_id, call->proto,
> > +				  call->conn->trans->local, addr_size,
> > +				  call->peer_ip.ipv6_addr);
> 
> The term 'ugh' springs to mind, but I don't think you can avoid all the
> pointing.

I thought it was more of an "ewww" myself. An alternative would be to add a 
struct rxrpc_call_hashinfo into struct rxrpc_call and pass that, but then I'd 
have to make one and populate it when doing the lookups.

As to the rest, I'll fix that up & resend. Actually I'm kind of waiting for 
you to tell me I've missed a trick in the call state handling, but at least 
the mistakes will be easier to spot now, I think.

-- 
Tim Smith <tim at electronghost.co.uk>
Pride dangles like a SPONGE
    -- FLCL
-------------- 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/20140214/32a52a99/attachment.sig>