>>>>> "jamal" == jamal <hadi@cyberus.ca> writes:
jamal> Hmm.. More complexity ;-> Does X.25 mandate you accept all
jamal> the window?
No. Just, if you do not accept a frame, you must not acknowledge it.
Once it has been acknowledged, you must not discard it.
jamal> Can you stop mid-window and claim there is
jamal> congestion? (maybe time to dust off some books).
Yes.
Just had a look at the X.25 specs again. As far as LAPB is concerned
(and thatīs what we are speeking about), it is like this:
When your receiver is busy, you tell the other end about this by means
of a ReceiverNotReady primitive. However, it might take some time until
the peer receives it and reacts on this. In the extreme case, there
could still arrive up to the window size frames. It seems that the
receiver can do whatever it wants to do with frames received during the
busy condition: Either accept the frames (but delay acknowledgement until
the busy condition is cleared) or just discard them. The first one seems
to favor performance while the second favors simplicity.
I guess in Linux, we should usually choose simplicity. I think even
with the simpicity variant, we could be able to preserve performance
if we can flow control the peer earlier. E.g. when the return value of
your netif_rx indicates 'almost congested, but still able to accept frames',
we could already set the busy condition but continue to deliver the
frames arriving during our busy condition. But thatīs performance tuning
and can be taken care of later (Iīm even not sure wheter this tuning will
pay off).
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:15 EST