[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ethmac] Pause




Hi,

   Well one more thing you might want to add when you get to it is that the trasmite machine when ever in Idle generate xon packet as just assume the case where you send xon and this packet got corrupted in the way .

a different/extra approach might be to have timer for xon that is reset everytime you have free buffer and got rx packet as the only problem with the above is incase you somehow in a situation where you ned to send tx packet all the time with no gap.

I had both but in practical the first is enough.

have a nice day

   Illan



-----Original Message-----
From: Igor Mohor [mailto:igorm@opencores.org]
Sent: Saturday, February 09, 2002 2:33 AM
To: ethmac@opencores.org
Subject: RE: [ethmac] Pause


Hi, Illan, guys

I said before that pause frame should be sent before all buffers are full.
Perhaps I'll change that in the future but at the moment other things have
the
priority (to make a version that will finally work on hw).

Regards,
	Igor

> -----Original Message-----
> From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
> Behalf Of Illan Glasner
> Sent: 8. februar 2002 21:31
> To: ethmac@opencores.org
> 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@opencores.org]
> Sent: Thursday, February 07, 2002 1:32 AM
> To: ethmac@opencores.org
> Subject: RE: [ethmac] Pause
>
>
> Hi, Jeff,
>
> please read my comments below.
>
> > -----Original Message-----
> > From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
> > Behalf Of zjli@technologist.com
> > Sent: 6. februar 2002 23:30
> > To: ethmac@opencores.org
> > 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
>
> > --
> > To unsubscribe from ethmac mailing list please visit
> http://www.opencores.org/mailinglists.shtml
>
> --
> To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml