Interface to MAC: Followup Jeff Mandin PMC-Sierra Maintenance Adhoc – August 2008

Aug Maintenance Adhoc2 Discussions since the first telecon Many perspectives on how to understand the interaction between the MAC client and the MAC via MA_DATA.Request(): a)There is implicit interaction between the MAC and the MA_DATA.Request primitive, so that the packet is not presented to the MAC until the MAC is ready for it -In one understanding this results in implicit queueing of the packet and increased latency -In another understanding, MA_DATA.Request might block in some cases b)Client is responsible for ensuring that it doesnt have multiple MA_DATA.Request() outstanding, but client state diagrams do not include this explicitly c)MAC interface should be modified d)Also some variations on the above

Aug Maintenance Adhoc3 On what issues is there some consensus? a)Each of the descriptions of the Client/MAC interaction on the previous slide has issues - none is wholly satisfactory b)To make a conclusive statement and to avoid future problems, there should be some discussions with experts in c)The MAC only processes one transmit request at a time -To the eyes of many readers, the current MAC Control diagrams (ie. PAUSE and MPCP) appear to flout this and transmit multiple requests

Aug Maintenance Adhoc4 Clarifying the MAC Control Diagrams Approaches: a)Add exit condition to the transmission states, so that the control flow does not advance until the MAC is ready -ie. make the magic step explicit -Does it lead to missed requests in the state diagram? Is it consistent with other MAC Clients? b)Add text to indicate that the state diagram describes transmission logic for a packet, and that the client is responsible for ensuring that it does not invoke MA_DATA.Request when the MAC is not ready - Work out the precise text after the discussion

Aug Maintenance Adhoc5 PAUSE State Diagram + exit condition

Aug Maintenance Adhoc6 MPCP Control Multiplexer