Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Question on ClassB client traffic




Prasad,

You are correct. I was being overly simplistic. There is a minimal amount of
buffering in the MAC for specifically this purpose. We call it the staging
queue. Its purpose is solely to accept a packet from the client with
sufficient timeliness to keep the staging queue ready to transmit a frame at
any time with no delay in fetching it from the client. One could think of it
as a prefetch. It is not a general purpose buffer that has a buffer full or
empty state conveyed to the client. Instead, the MAC, when it has room in
the staging queue, raises the appropriate sendX signal. One the packet has
been received from the client, it should be viewed as being on the wire.

jl

-----Original Message-----
From: Prasad Modali [mailto:prasad_modali@xxxxxxxxxxxxxxx]
Sent: Tuesday, July 02, 2002 12:26 PM
To: John Lemon
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Question on ClassB client traffic


John,

If we do not have any buffering in the MAC, we'd bring down
the peformance of the client interface. For example, scheduler
could decide to accept an insert packet if there is no class A
transit packet at that moment. The client could take few clock
cycles to respond to the send signal. Meanwhile, we could have
a class A transit packet available. This will require us to
buffer the client packet in the MAC or throttle the class A
transit traffic until client responds and completes the packet
transfer. How do we address this scenario?

prasad

> -----Original Message-----
> From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> Sent: Monday, July 01, 2002 2:52 PM
> To: 'Prasad Modali'
> Cc: Anil Nangunoori; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Question on ClassB client traffic
>
>
> Prasad,
>
> There is no buffer-full type of back pressure because the add queues (or
> buffers) are maintained by the client, not the MAC. Depending upon the
> implementation, the client may push a packet out of an add queue when the
> associated Send signal is active, or the MAC may pull a packet
> out of an add
> queue when the associated Send signal is active. In the former case, the
> client would need to use the Send signals to figure out when to send and
> what to send. In the latter case, the client could ignore the signals and
> just keep stuffing its queues. It's an implementation decision.
>
> jl
>
> -----Original Message-----
> From: Prasad Modali [mailto:prasad_modali@xxxxxxxxxxxxxxx]
> Sent: Thursday, June 27, 2002 6:11 PM
> To: Stds-802-17
> Cc: Anil Nangunoori
> Subject: [RPRWG] Question on ClassB client traffic
>
>
>
> Hi All,
>
> Annex I in D0.3 describes the MAC client behavior. The
> packet forwarding logic in the MAC has to give priority to
> the ClassA transit traffic. So a client inserting ClassB
> packets into the MAC could be back pressured by a burst
> of ClassA transit traffic.
>
> How does the client distinguish between buffer-full type
> of back pressure vs. ClassB rate shaping(tokens expiry)
> related back pressure? When classB tokens expire, client
> can still send classB packets if SendC is asserted.
>
> thanks
>
> --
> Prasad Modali
> Chip Engines Inc
> (408)991-9800 x116
>