netdev - Re: Regarding Routing cache

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADAe=+K8bf_VOe=KszDZRqZnxQH2VFS3C05mpG=RarN+R5BSbA@mail.gmail.com>
Date:	Thu, 17 Nov 2011 11:34:08 +0530
From:	Ajith Adapa <adapa.ajith@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: Regarding Routing cache

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.

Regards,
Ajith




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