| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: Q: sock output serialization |
| From: | Henner Eisen <eis@xxxxxxxxxxxxx> |
| Date: | Tue, 19 Sep 2000 22:48:45 +0200 |
| Cc: | alan@xxxxxxxxxxxxxxxxxxx, davem@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <Pine.GSO.4.20.0009172129060.979-100000@shell.cyberus.ca> (message from jamal on Sun, 17 Sep 2000 21:38:38 -0400 (EDT)) |
| References: | <Pine.GSO.4.20.0009172129060.979-100000@shell.cyberus.ca> |
| Sender: | owner-netdev@xxxxxxxxxxx |
>>>>> "jamal" == jamal <hadi@xxxxxxxxxx> writes:
jamal> Packets in flight?
>> In the extreme case, there could still arrive up to the window
>> size frames.
jamal> Assuming this depends on path latency and not some bad
jamal> programming
Yes. Although the latter could also possible.
jamal> BTW, earlier i lied: there is a way to tell if your packet
jamal> will be dropped which is not very expensive:
jamal> if (atomic_read(&netdev_dropping) /* packet will be
jamal> dropped */
jamal> but even this is 99% accurate in SMP.
Well, but better than knowing nothing about congestion state.
We could at least document in the x25iface.txt kernel doc that driver
authors should check this before acknowledging frames.
Henner
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: forwarding packets, mcr |
|---|---|
| Next by Date: | Re: [PATCH/RFC] (long) network interface changes, Henner Eisen |
| Previous by Thread: | Re: Q: sock output serialization, jamal |
| Next by Thread: | Re: Q: sock output serialization, Andi Kleen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |