On Fri, Apr 07, 2006 at 03:50:54AM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > This change removed stackable output processing, which was a good idea by > > design (and there are users outside the kernel, like asynchronous crypto > > processing for IPsec). > > Is there any reason why you can't do async crypto with the existing > framework? As far as I can see it should work fine since it's not that > different from netfilter queueing.
I use different approach than netfilter queueing for performance reason (acrypto allows to do synchronous crypto too, although some allocation price is always paid). Current xfrm output processing is very simillar to how input is implemented, both do not use internals of dst_* methods and implement stack of commands as loop inside appropriate input or output callback. Previous implementation used real stackable technique for output processing, so it was very easy to setup new output method for dst child end return magic value from current output method. After this step network stack forgot about skb, which later will be reinjected on completion of crypto processing. Input engine never used such a stack, so I need to create big structure to hold input states and change quite a few xfrm input pathes to make it asynchronous. I'm not saying new schema is bad or good, I will port acrypto ipsec processing to this loop approach like it is done for input, that is a price of being out of the tree :) I just wonder why stackable dst_output() was removed? > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
