Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 21:11:09 + > I can put in a limit per peer, where a 'peer' is either a particular remote > UDP port or particulat remote host. TCP has this by virtue of having a > limited number of ports available per IP address. But if I

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 21:11:09 + > I can put in a limit per peer, where a 'peer' is either a particular remote > UDP port or particulat remote host. TCP has this by virtue of having a > limited number of ports available per IP address. But if I have 10 IP > addresses

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > > One could argue, I suppose, that things should've been arranged that the > > RxRPC client would manage the lifetime of each connection it sets up, > > rather than both ends letting it lapse by mutual loss of interest. But > > you *still* have to have

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > > One could argue, I suppose, that things should've been arranged that the > > RxRPC client would manage the lifetime of each connection it sets up, > > rather than both ends letting it lapse by mutual loss of interest. But > > you *still* have to have a timeout, lest the

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 13:02:28 + > David Howells wrote: > >> Does it make sense to maintain a FIFO list of connections (though this would >> mean potentially taking a spinlock every time I get a packet)? > > It occurs to me

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 13:02:28 + > David Howells wrote: > >> Does it make sense to maintain a FIFO list of connections (though this would >> mean potentially taking a spinlock every time I get a packet)? > > It occurs to me that only inactive connections would need to

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 11:39:57 + > One could argue, I suppose, that things should've been arranged that the RxRPC > client would manage the lifetime of each connection it sets up, rather than > both ends letting it lapse by mutual loss of interest.

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Tue, 08 Mar 2016 11:39:57 + > One could argue, I suppose, that things should've been arranged that the RxRPC > client would manage the lifetime of each connection it sets up, rather than > both ends letting it lapse by mutual loss of interest. But you *still* have

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Howells wrote: > Does it make sense to maintain a FIFO list of connections (though this would > mean potentially taking a spinlock every time I get a packet)? It occurs to me that only inactive connections would need to be on an LRU list. Any connection with packets

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Howells wrote: > Does it make sense to maintain a FIFO list of connections (though this would > mean potentially taking a spinlock every time I get a packet)? It occurs to me that only inactive connections would need to be on an LRU list. Any connection with packets or active calls to

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > >> I know you put a lot of time and effort into this, but I want to strongly > >> recommend against a garbage collected hash table for anything whatsoever. > >> > >> Especially if the given objects are in some way created/destroyed/etc. by > >>

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > >> I know you put a lot of time and effort into this, but I want to strongly > >> recommend against a garbage collected hash table for anything whatsoever. > >> > >> Especially if the given objects are in some way created/destroyed/etc. by > >> operations triggerable

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Mon, 07 Mar 2016 22:45:14 + > David Miller wrote: > >> I know you put a lot of time and effort into this, but I want to strongly >> recommend against a garbage collected hash table for anything whatsoever. >> >>

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Mon, 07 Mar 2016 22:45:14 + > David Miller wrote: > >> I know you put a lot of time and effort into this, but I want to strongly >> recommend against a garbage collected hash table for anything whatsoever. >> >> Especially if the given objects are in some way

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > I know you put a lot of time and effort into this, but I want to strongly > recommend against a garbage collected hash table for anything whatsoever. > > Especially if the given objects are in some way created/destroyed/etc. by > operations triggerable

Re: [PATCH 01/11] rxrpc: Add a common object cache

David Miller wrote: > I know you put a lot of time and effort into this, but I want to strongly > recommend against a garbage collected hash table for anything whatsoever. > > Especially if the given objects are in some way created/destroyed/etc. by > operations triggerable remotely. > > This

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Mon, 07 Mar 2016 14:38:06 + > Add a common object cache implementation for RxRPC. This will be used to > cache objects of various types (calls, connections, local and remote > endpoint records). Each object that would be cached must contain an

Re: [PATCH 01/11] rxrpc: Add a common object cache

From: David Howells Date: Mon, 07 Mar 2016 14:38:06 + > Add a common object cache implementation for RxRPC. This will be used to > cache objects of various types (calls, connections, local and remote > endpoint records). Each object that would be cached must contain an > obj_node struct

[PATCH 01/11] rxrpc: Add a common object cache

Add a common object cache implementation for RxRPC. This will be used to cache objects of various types (calls, connections, local and remote endpoint records). Each object that would be cached must contain an obj_node struct for the cache to use. The object's usage count and link pointers are

[PATCH 01/11] rxrpc: Add a common object cache

Add a common object cache implementation for RxRPC. This will be used to cache objects of various types (calls, connections, local and remote endpoint records). Each object that would be cached must contain an obj_node struct for the cache to use. The object's usage count and link pointers are