Thanks! I had though about this in the last two days and a half, and there is still something which I cannot understand and it bothers me (while trying vainlesly to sleep).
I am talking about IPV4: - Can anyone explain in 2-3 sentences what is the reason that there is no need for caching dst_entries which are created by IPsec (using xfrm API) ? I can understand , in case there is a linked list of such dst_enties, that there is no need to cache them all because you can access them by traversing the list with the child pointer of dst_entry. But what about the head of the list, which is the first dst_entry (which is created by IPsec and its input/output methods are in fact IPsec transformers)? is there no need to cache this entry ? because as I understand it , next sk_buff with the same dest IP will have to get this same dst_entry (the head of the list). So why not cache this head of the list of dst_entries ? Regards, Ian On Nov 27, 2007 3:57 AM, Herbert Xu <[EMAIL PROTECTED]> wrote: > Ian Brown <[EMAIL PROTECTED]> wrote: > > > > NOHASH hints that we do not keep the > > an entry in a hash. I doubt that such dst_entries , which are created with > > IPsec and so has the DST_NOHASH flag set, are not kept in the routing cache? > > Exactly, they're not in the routing cache (for IPv4 anyway, > there is no cache at all for IPv6). > > > 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 > - 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
