| To: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC/PATCH] "strict" ipv4 reassembly |
| From: | Ben Greear <greearb@xxxxxxxxxxxxxxx> |
| Date: | Tue, 17 May 2005 12:26:23 -0700 |
| Cc: | jheffner@xxxxxxx, ak@xxxxxx, netdev@xxxxxxxxxxx, akepner@xxxxxxx |
| In-reply-to: | <20050517.120950.74749758.davem@xxxxxxxxxxxxx> |
| Organization: | Candela Technologies |
| References: | <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <m1zmut7l5q.fsf@xxxxxx> <200505171457.38719.jheffner@xxxxxxx> <20050517.120950.74749758.davem@xxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 |
David S. Miller wrote: From: John Heffner <jheffner@xxxxxxx> Date: Tue, 17 May 2005 14:57:38 -0400It would be better still to have a per-route packet reassembly timeout in milliseconds.I agree. And if we can setup the infrastructure such that the drivers can indicate the speed of the link they are communicating on, then we can set sane default values on the automatically created subnet routes. I assume you mean more than local physical link speed? Imagine: GigE server -- gige-core -- 10bt hub -- gige-core -- gige client Now, this particular setup would be lame, but the 10bt hub could really be a bridged WAN, wireless or other slow and not-so-easily upgraded network link. Local link speed is relatively easy to figure out using ethtool for the NICs that support it at least.... Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com |
| Previous by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Nivedita Singhvi |
|---|---|
| Next by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, John Heffner |
| Previous by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Rick Jones |
| Next by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Thomas Graf |
| Indexes: | [Date] [Thread] [Top] [All Lists] |