Regarding Routing cache

Regarding Routing cache

[Ajith Adapa]

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

Re: Regarding Routing cache

[Ajith Adapa]

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@gmail.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
>

Re: Regarding Routing cache

[Eric Dumazet]

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@gmail.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
> >
> --

Re: Regarding Routing cache

[Eric Dumazet]

Please, no private mails on this discussion. I added back netdev on CC.

Le jeudi 17 novembre 2011 à 12:09 +0530, Ajith Adapa a écrit :
> Hi,
> 
> Sorry about my naive post regarding the issue.
> 
> > IPv6 has no routing cache, and wont have one, since we are trying to
> > remove IPv4 routing cache :)
> 
> But it would have performance issues right as we always check fib
> table for destination route ?
> 
> Is there any references or posts or material which takes about the
> reason for removing the ipv6 and ipv4 routing caches ?
> 

routing cache doesnt scale and was difficult to tune in some situations.

It uses a lot of memory, and doesnt fit in CPU caches.

It was a good solution in the past, but better is to get scalable algo
in the first place.

http://vger.kernel.org/netconf2011.html

http://vger.kernel.org/netconf2011_slides/davem_netconf2011.pdf