On Sun, 17 Sep 2000, Henner Eisen wrote:
> >>>>> "jamal" == jamal <hadi@cyberus.ca> writes:
> No. Just, if you do not accept a frame, you must not acknowledge it.
> Once it has been acknowledged, you must not discard it.
Ok so no problem then
>
> jamal> Can you stop mid-window and claim there is
> jamal> congestion? (maybe time to dust off some books).
>
> Yes.
Again, this makes life simpler. You dont have to accept the whole window.
> 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.
Packets in flight?
> In the extreme case, there could still arrive up to the window size
> frames.
Assuming this depends on path latency and not some bad programming
> 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).
>
This is doable. the 'almost congested, but still able to accept frames'
is a tunable parameter via proc.
Nobody is stopping you from maintaining your own little queue in the
driver to take the first option. The complexity is added to your driver as
opposed to the general system.
BTW, earlier i lied: there is a way to tell if your packet will be dropped
which is not very expensive:
if (atomic_read(&netdev_dropping)
/* packet will be dropped */
but even this is 99% accurate in SMP.
cheers,
jamal
-
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