From: "David S. Miller" <davem@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: niv@us.ibm.com, ak@suse.de, ruddk@us.ibm.com,
kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com,
chester.f.johnson@intel.com
Subject: Re: PMTU issues due to TOS field manipulation (for DSCP)
Date: Wed, 10 Dec 2003 15:20:39 -0800 [thread overview]
Message-ID: <20031210152039.055e887a.davem@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0312110103280.1519-100000@u.domain.uli>
On Thu, 11 Dec 2003 01:15:06 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:
> It seems, there are no many users of OIF!=0 but if TOS is
> used as routing key we can see up to 8 entries with different
> TOS for same SADDR,DADDR. Of course, it looks difficult to
> walk 8 rows just to check all TOS variants, the common case
> is to see only one TOS value used. That is why I propose
> to eliminate the TOS as hash key and to walk one row. At first
> look, the risk of DoS is same, thanks to the random value.
This is not my understanding at all.
Consider the case where we generate routing cache entries for
all 8 TOS values. Currently we'll likely get a O(1) lookup
for any one of those entries.
Your proposal guarentees that all such entries will land to the
same hash chain, since TOS is not an input for the hash any longer.
Therefore the lookup in my example case will be O(8).
And instead of just eating the complexity at ICMP PMTU handling
time, we eat the complexity at every routing cache lookup.
I really don't think we can consider this.
next prev parent reply other threads:[~2003-12-10 23:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-10 18:23 PMTU issues due to TOS field manipulation (for DSCP) Kevin W. Rudd
2003-12-10 19:34 ` Andi Kleen
2003-12-10 20:20 ` Julian Anastasov
2003-12-10 20:33 ` Nivedita Singhvi
2003-12-10 21:18 ` Julian Anastasov
2003-12-10 22:36 ` Nivedita Singhvi
2003-12-10 22:51 ` David S. Miller
2003-12-10 23:15 ` Julian Anastasov
2003-12-10 23:20 ` David S. Miller [this message]
2003-12-11 0:06 ` Julian Anastasov
2003-12-11 0:09 ` David S. Miller
2003-12-11 0:34 ` Julian Anastasov
2003-12-12 8:31 ` David S. Miller
2003-12-12 23:38 ` Julian Anastasov
2003-12-18 23:17 ` Kevin W. Rudd
2004-01-19 22:43 ` Kevin W. Rudd
2004-01-20 4:29 ` David S. Miller
2003-12-13 0:10 ` Julian Anastasov
2004-03-04 9:36 ` David S. Miller
2004-03-04 20:56 ` Julian Anastasov
2004-03-04 22:02 ` kuznet
2004-03-06 11:55 ` Julian Anastasov
2004-03-06 16:02 ` Julian Anastasov
2003-12-10 20:26 ` Kevin W. Rudd
2003-12-10 20:52 ` Andi Kleen
2003-12-10 20:30 ` Nivedita Singhvi
2003-12-10 20:55 ` Andi Kleen
2003-12-10 21:11 ` Nivedita Singhvi
-- strict thread matches above, loose matches on Subject: below --
2003-12-10 21:35 Johnson, Chester F
2003-12-10 23:36 Johnson, Chester F
2003-12-11 0:17 ` Julian Anastasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031210152039.055e887a.davem@redhat.com \
--to=davem@redhat.com \
--cc=ak@suse.de \
--cc=chester.f.johnson@intel.com \
--cc=ja@ssi.bg \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@oss.sgi.com \
--cc=niv@us.ibm.com \
--cc=ruddk@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).