From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 24 Mar 2006 22:51:16 +1100
On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
Here it is, against 2.6.16-rc3.
OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
more references to tos in ip_rt_redirect.
On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
Here it is, against 2.6.16-rc3.
OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
more references to tos in ip_rt_redirect. Please note that the author
of this patch is Ilia Sotnikov [EMAIL PROTECTED].
From:
On 2/15/06, Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, Feb 15, 2006 at 03:21:50PM +0200, Ilia Sotnikov wrote:
Totally agree but perhaps we should ask the confirmation from someone?
That's what this list is for :) Send a patch and if there are no objections
it should be go in.
Here it is,
On 2/15/06, Herbert Xu [EMAIL PROTECTED] wrote:
How about dropping TOS from the hash code instead? How many people
out there actually route using the TOS and use more than two TOS values?
Totally agree but perhaps we should ask the confirmation from someone?
The removal of routing decisions by
On Wed, Feb 15, 2006 at 03:21:50PM +0200, Ilia Sotnikov wrote:
Totally agree but perhaps we should ask the confirmation from someone?
That's what this list is for :) Send a patch and if there are no objections
it should be go in.
The removal of routing decisions by TOS field would made the
Recently we run into the problems with Path MTU Discovery.
An Internet host sent ICMP 3/4 Fragmentation needed and DF bit set
message but included IP header of original packet had diferent TOS
field rather than we sent. As far as I know it's permitted and some of
ISPs do that to implement their
On 2/15/06, Herbert Xu [EMAIL PROTECTED] wrote:
What about doing this unconditionally?
In some cases the patch could led to a large number of lookups on
rt_hash_code over all possible TOS values (additional 8 passes). In
complex configurations with many routing tables it could be
