|
Message
From: "Illan Glasner" <iglasner@z...>
Date: Fri, 8 Feb 2002 12:30:40 -0800
Subject: RE: [ethmac] Pause
Hi,
While this is perfectly ok it also mean if you are in the begining of sending one large packet by the time you send the stop you can already get about 30 small packet and overflow your input buffers or to prevent it you need to start sending stop when you still have enough buffer for about 30 packets.
The method I used was in case of any change in the flow control status wether it is to send start or stop is to stop the trasmission of the packet send the flow control and re-send the packet.
assuming the MAC can handle also half-duplex this is simple done by telling the "back side" you had collision so it retransmite the packet while masking the collision counter this way you can act fast for any change in the buffers while not needing to allocate large amount of buffers.
have a nice day
Illan
-----Original Message-----
From: Igor Mohor [mailto:igorm@o...]
Sent: Thursday, February 07, 2002 1:32 AM
To: ethmac@o...
Subject: RE: [ethmac] Pause
Hi, Jeff,
please read my comments below.
> -----Original Message-----
> From: owner-ethmac@o... [mailto:owner-ethmac@o...]On
> Behalf Of zjli@t...
> Sent: 6. februar 2002 23:30
> To: ethmac@o...
> Subject: [ethmac] Pause
>
>
> This core stops transmitting upon receiving a control frame only after
> having finished sending the current frame. Am I right?
Yes.
> Can it be a very
> long time between receiving the control frame and starting to pause? I
> do not see any requirement in IEEE 802.3, but is it important to react to
> the PAUSE request more quickly than waiting for a frame to finish?
I disagree with you. Let's say that you just start with frame transmission
when
you received the pause request. You'll stop sending frames after this one.
So there is max. 1 frame delay. Receiving station sends pause request not
when it is full but when it is close to full.
>
> Thanks,
> Jeff
Regards,
Igor
>
|
 |
Browse
