netdev
[Top] [All Lists]

Re: dst_entry and friends

To: Gabriel Paues <gabriel@xxxxxxx>
Subject: Re: dst_entry and friends
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 29 Apr 2002 16:55:03 +0200
Cc: netdev@xxxxxxxxxxx
In-reply-to: <3CCD1D18.F33EAEE8@xxxxxxx>
References: <15561.20004.964497.762468@xxxxxxxxxxxx> <3CCD1D18.F33EAEE8@xxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.3.22.1i
On Mon, Apr 29, 2002 at 12:14:48PM +0200, Gabriel Paues wrote:
> My idea is to use netfilter and in the PRE_ROUTING-hook check the flowlabel 
> for
> values other than zero, and set the dst_entry in the skbuff to something with
> its input-function to ip6_output. I dont know if I should allocate this
> fabricated dst_entry myself or if I should scan the list of already existing
> ones. By setting the input-function-pointer to ip6_output i will skip the 
> whole

That won't work for most networking protocols, which always route themselves.
All you can do is to drop the route later in netfilter and reroute/resubmit

Still your concept will fail for path mtu discovery for example, which
assumes that an incoming ICMP can be matched to an dst_entry in the routing
cache to communicate the new pmtu. 

It may be easier to just change ip_route_output(). Routes are often 
cached however, so you would need to make sure that the caches 
are invalidated when the flow label changes (e.g. by setting dst->obsolete) 

Overall the concept does not look very promising however. I guess to make 
the labels unique you'll have to add srcip/dstip to your private tables too,
and that means that the label lookup is exactly equivalent in cost to 
a normal routing cache lookup - even if you didn't need the src/dst it 
probably wouldn't be much cheaper.

-Andi

<Prev in Thread] Current Thread [Next in Thread>