About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Mon, 08 Oct 2007

Climbing evening.

Although it is quite hard to call it 'climbing', since I rubbed my foot very seriously, so I an not even move stright (live anti-advertisement of the climbing zone), not talking about climbing in several sizes smaller shoes. So I hurt myself and my foot couple of hours and moved home - I will have a delay in climbing training until next week, hopefully foot will be ok then.

/life :: Link / Comments (0)

Async IPsec support in Linux kernel.

Herbert Xu (current crypto maintainer) started preparatory work to move IPsec to become asynchoronous - so far he moved common code around into generic helpers, added skb shared structure to hold XFRM (linux IPsec stack) per-packet state (header and sequence number) during IP processing, which includes time while packet is being encrypted, and also removed (or replaced) potentially unused/redundant elements during XFRM processing.
As is, it does not add any async possibilities, since the main output loop, where crypto (ESP or AH) processing function is called, was not broken into completion parts, but with above changes it will be much simpler.
For example acrypto async IPsec patch, which was introduced for 2.6.15 kernel tree, did not have common code for IPv6 and IPv4 processing code, so it only supported IPv4 ESP mode.
I'm pretty sure Herbert will implement async processing as a callback invocation model (although I saw implementation of a crypto function as a busy waiting for completion), when skb will contain all information needed for further packet handling (mainly it is either routing information or device output function, obtained from routing info), and that callback will be provided to encryption device. One big problem with such apporach can be that crypto hardware device (actually the only one real async hardware supported by existing Linux crypto stack is HIFN 795x adapters) can call provided callbacks from hardirq context instead of softirq (or process context) like in current network stack.
We will see, how this will be implemented. I really wish Herbert success and hope it will find its way into 2.6.24 tree (ugh, I need to complete misaligned handling in HIFN driver, but new driver policy is a bit less restrictive in matter of time limits after merge window is opened by Linus, so I will try really hard to kill my laziness, so that driver will be ready this week).

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