[lkml]   [2000]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Q: sock output serialization
>>>>> "jamal" == jamal  <> 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).


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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.065 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site