About TODO Blog RSS Old blog Projects Gallery Notes

Thu, 01 Nov 2007

Network hash tables for socket lookups.

Topic of moving hash tables to RCU rises regulary in netdev@ mail list, but so far there is no solution for hash resizing problem because of RCU nature. Likely it can not be fixed at all without some additional (maybe optional) synchronization.
It was pointed that Robert Olsson's hashed trie can be a good solution.

Interested reader can also check my multidimensional trie algorithm, which I implemented for network sockets lookup and originally got from netchannels. It was announced at netdev@ bug I got quite passive response, so froze the project for a while (it can be resurrected though)...
At the links above you can find performance testing comared to hash tables in kernel with different sizes. Testing was performed by running simple web server and huge number of clients, which frequently connect/disconnect from server.

/devel/networking :: Link / Comments (0)

DST status.

Checksumming found to be not that trivial problem - I implemented it with sync operation, which might become a bottleneck in case of reading (current implementation after sending read request sleeps and waits for the reply header with checksum instead of processing other requests), so I'm about to add another case into network state machine - header, data and checksum if needed.
Also fixed number of bugs, which I previously did not notice because of not scrutinized enough testing (like problem with single-node mirroring or single client userspace server, which already has a client).

Also found an interesting moment with network ->sendpage() method and buffers - it is not allowed to provide there SLAB pages (i.e. those with zero reference counter), although I'm pretty sure it was allowed some time ago.
So right now there is no way to zerocopy a header via ->sendpage(). Operation where this trick was used is initial mirror setup when node reads its age from the storage, which can be remotely exported node.

There is another issue with the protocol - block layer requires to have per page header 9actually per bio vector), since it is possible to have a non-contiguous block request (or not? I never saw a single request, which consisted of several bio vectors, where each one (or at least another one except the first and the last) has a not full page). Actually if such setup is not allowed (i.e. all pages in bio form a contiguous region on device), it would be possible to noticebly reduce size of the bio vector array and have better protocol for distributed storage.

After state machine extension got implemented, I will make a new release, very likely this will happen tomorrow.
This one will be really good release, so I will likely add a name for it.

Stay tuned!

/devel/dst :: Link / Comments (4)