lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 17 Nov 2011 07:26:54 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Ajith Adapa <adapa.ajith@...il.com> Cc: netdev@...r.kernel.org Subject: Re: Regarding Routing cache Please dont top post on netdev Le jeudi 17 novembre 2011 à 11:34 +0530, Ajith Adapa a écrit : > Hi, > > Actually I have doubt with IPv6 related packets. > > In case of IPv6 packet in ip6_route_output function is called for > destination related information. > where ip6_route_output calls "fib6_rule_lookup" function. Why lookup > is done in fib table instead of routing cache in case of IPv6 packet ? > > In case of IPv4 packet ... ip_route_output checks in routing cache and > if there is a cache miss then it checks the fib table. > IPv6 has no routing cache, and wont have one, since we are trying to remove IPv4 routing cache :) > > > > On Thu, Nov 17, 2011 at 10:30 AM, Ajith Adapa <adapa.ajith@...il.com> wrote: > > Hi, > > > > I have a small doubt regarding routing cache in linux kernel. > > > > It seems ip_route_connect is the way we have to access routing cache > > entries. In case of all locally generated packets I see that struct > > dst_entry is filled up with a lookup in routing cache. > > > > What about in case of forwarding packets ? I dont see any usage of > > routing cache mechanism to fill up the struct dst_entry. So it seems > > we directly check the fib_rules or fib table to fill the structure. > > If it is true then it would be very slow right ? > > > > Sorry if I am wrong about above findings. Do correct me if I am wrong about it ? > > > > Regards, > > Ajith > > > -- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists