| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Denis, No clauses of 802.3 need to be modified to account for 802.1Qbb use with IET. With IET, each MAC has an optional MAC Control sublayer that operates as it always does. If you think that I’m wrong, please point out exactly what needs to change.
I also don’t think that the PAUSE annex needs to change for IET. It is enough to say that PAUSE should not be enabled when IET is supported. We don’t need to add a connection between MAC Control and IET. It could be handled by stating that
in Clause 99. Potentially a sentence could also be added to the PAUSE annex. If the Express traffic is all scheduled traffic or controlled by a credit-based shaper the extra head room required is finite – one needs enough to cover the longest Express traffic gate or the maximum amount of credit that can accumulate.
Therefore, in theory extra headroom buffer could be configured to cover the Express traffic configuration and PFC frames sent on the pMAC. I don’t think that will be a common choice, but it is feasible depending on the transmission selection configuration
for the express traffic. In any case, that is not an 802.3 br issue nor is it a general 802.3 issue. The only thing that MAC Control does for Qbb is send the PFC frame. Sending of the PFC frame from the selected MAC Control sublayer operates without any modification.
The bulk of PFC is specified in 802.1Q and it is 802.1Qbu that should include material on how to use 802.1Qbu and PFC together. This was discussed at the TSN meeting so they know it needs to be done.
Regards, Pat From: Beaudoin, Denis [mailto:dbeaudoin@xxxxxx]
I agree if we are IET then 802.3x link based flow control should not be used as it breaks the TSN capability, but the 802.3br group must modify the clauses within 802.3 that currently document the link based
flow control operation. That is 802.3br enabled forces 802.3x operation to be disabled. As far as 802.3bd/802.1Qbb, if PFC frames are not on the express traffic MAC then the run out required goes to infinite since express traffic can continuously starve the preemptable MAC. 802.1Qbb ensures that there is no loss on any of the N priorities supported in 802.1Qbb, the only solution is to allow PFC on express MAC. But once again, the associated clauses within 802.3 need to be modified
to account for operation. Regards Denis Beaudoin DMTS Texas Instruments
dbeaudoin@xxxxxx
W: 214-480-3287/77 M: 214-475-9193 From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Currently, flow control isn’t mentioned. It was discussed a bit last week (possibly during the TSN comment resolution on 802.1bu).
802.3x (i.e. PAUSE) shouldn’t be used with IET, IMO. A comment to suggest that on the WG ballot would be appropriate. One shouldn’t pause the whole link when handling time sensitive traffic – it defeats the purpose.
In theory, one could define it as PAUSING only the preemptable traffic as it operates in MAC Control and there is one per MAC, but the PAUSE would have to be received by the same MAC so it wouldn’t work when your link partner doesn’t have
IET active yet (all frames carry an SFD and are delivered to the eMAC and so to the eMAC MAC Control) and, even when preemption is active, it is still impractical because you wouldn’t be able to send a PAUSE from the pMAC MAC Control when express traffic was
being transmitted so PAUSE frames are unlikely to arrive in a timely manner. There could be ways around those limitations but we have PFC so it isn’t worth changing 802.3x to make it work. If you need to PAUSE some of the preemptable priorities, use PFC. I expect that the 802.1Qbu draft will add something on how to use PFC (802.1Qbb and 802.3bd) with it as a result of the discussions. The mechanism for it runs above the MAC so it doesn’t matter to the mechanism which MAC receives the PFC
frame. The MAC client can decide which MAC Control sends the PFC frame by which MAC Client interface it chooses for the MAC Control primitive. Since each has an optional MAC Control sublayer the standard doesn’t have to dictate which is used.
Generally sending it on the eMAC is more likely as it will be transmitted as soon as the current eMAC frame is finished or the current pMAC frame can either be preempted or finished. But that assumes that the express traffic can tolerate the latency jitter
of having a PFC frame go ahead of it. The other alternative is to send it on the pMAC MAC Control and have enough additional buffer headroom to allow for having to wait to send it while express traffic is sent – but that may need way too much buffer or be
unpredictable in non-scheduled traffic scenarios. I don’t think we need to say anything about the use of PFC with 802.3br.
Regards, Pat From: Winkel, Ludwig [mailto:ludwig.winkel@xxxxxxxxxxx]
Denis, Why you are asking this? In my mind the flow control is no more needed. At least the combination makes no sense for me from the standpoint of applications. There was a similar discussion during the joint .1TSN and .3br meeting with the conclusion that flow control can be substituted by this better approach of IET
combined with the different .1TSN approaches on top. Mit freundlichen Gruessen / With best regards,
Chair of the IEEE P802.3br Task Force Co-chair of IEC SG8 Convenor of IEC SC65B/WG16 Convenor of IEC SC65C/WG17 Convenor of IEC SC65C/MT9 Convenor of CENELEC TC65X/WG1 Mail: Siemens AG , PD TI FC
From: Beaudoin, Denis [mailto:dbeaudoin@xxxxxx]
Ludwig,
Glancing through the latest
P802.3br, there is no comment on the operation between IET (P802.3br) and flow control. Is 802.3x link based flow control possible? Is 802.3bd priority based flow control possible? If either is possible, are they on the express MAC or preemptable MAC? Regards Denis Beaudoin DMTS Texas Instruments
dbeaudoin@xxxxxx
W: 214-480-3287/77 M: 214-475-9193 From: Winkel, Ludwig [mailto:ludwig.winkel@xxxxxxxxxxx]
Dear IET colleagues, This evening, the IEEE 802.3 approved unanimously, in its closing plenary, starting WG ballot on IEEE P802.3br, D2.0. Pat will produce D2.0 by removing the change tracking
information and updating the first page. The closing plenary report of IET rev 0 was changed according to the latest motion to add a needed sentence in the WG motion and during the closing plenary I was requested
to change the D1.9 to D2.0 in the motion. This resulting closing plenary presentation of IET is on the server as rev1. Please be prepared that I will announce in conjunction with Michael for 802.1 TSN that we will have a series of joint teleconference meetings to do initial comment resolution
before the next interim in Pittsburgh using the day and time of the usual 802.1 TSN meetings. Mit freundlichen Gruessen / With best regards,
Chair of the IEEE P802.3br Task Force Co-chair of IEC SG8 Convenor of IEC SC65B/WG16 Convenor of IEC SC65C/WG17 Convenor of IEC SC65C/MT9 Convenor of CENELEC TC65X/WG1 Mail: Siemens AG , PD TI FC
|