| To: | David Stevens <dlstevens@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC/PATCH] "strict" ipv4 reassembly |
| From: | John Heffner <jheffner@xxxxxxx> |
| Date: | Tue, 17 May 2005 16:29:08 -0400 |
| Cc: | Andi Kleen <ak@xxxxxx>, akepner@xxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <OF0221F508.AD091D99-ON88257004.006D0C52-88257004.006D8293@us.ibm.com> |
| Organization: | PSC |
| References: | <OF0221F508.AD091D99-ON88257004.006D0C52-88257004.006D8293@us.ibm.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | KMail/1.8 |
On Tuesday 17 May 2005 03:56 pm, David Stevens wrote: > Dave, > Shouldn't that be an estimator on the destination RTT? Or is that Unfortunately, it's not the RTT that matters, but link speed. You could probably do some heuristics on this, but I don't know if it's worth the effort. IMO, high-rate applications which rely on IP fragmentation and a 16-bit ones complement for data integrity are broken, and a band-aid style workaround for them is probably good enough. As long as it's not inflicted on the rest of us. :) -John |
| Previous by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Andi Kleen |
|---|---|
| Next by Date: | Re: Qdisc requeue should be void?, Patrick McHardy |
| Previous by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Rick Jones |
| Next by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Nivedita Singhvi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |