Revision 10717f45639f6c1bc27b56405252c3a027406d92 authored by Trond Myklebust on 27 January 2020, 14:58:19 UTC, committed by Anna Schumaker on 03 February 2020, 21:35:07 UTC
Delegations can be expensive to return, and can cause scalability issues for the server. Let's therefore try to limit the number of inactive delegations we hold. Once the number of delegations is above a certain threshold, start to return them on close. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
1 parent d2269ea
TODO
Steve's quick list of things that need finishing off:
[they are in no particular order and range from the trivial to the long winded]
o Proper timeouts on each neighbour (in routing mode) rather than
just the 60 second On-Ethernet cache value.
o Support for X.25 linklayer
o Support for DDCMP link layer
o The DDCMP device itself
o PPP support (rfc1762)
o Lots of testing with real applications
o Verify errors etc. against POSIX 1003.1g (draft)
o Using send/recvmsg() to get at connect/disconnect data (POSIX 1003.1g)
[maybe this should be done at socket level... the control data in the
send/recvmsg() calls should simply be a vector of set/getsockopt()
calls]
o check MSG_CTRUNC is set where it should be.
o Find all the commonality between DECnet and IPv4 routing code and extract
it into a small library of routines. [probably a project for 2.7.xx]
o Add perfect socket hashing - an idea suggested by Paul Koning. Currently
we have a half-way house scheme which seems to work reasonably well, but
the full scheme is still worth implementing, its not not top of my list
right now.
o Add session control message flow control
o Add NSP message flow control
o DECnet sendpages() function
o AIO for DECnet
Computing file changes ...
