FW: Comment on T10/13-138r0 SPL-3 CREDIT ADVANCE for OPEN_ACCEPT

Craig Stoops Craig.Stoops at synopsys.com
Thu Sep 19 14:39:53 PDT 2013


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1309192_f.htm">HTML-formatted message</a>

Hi Tim,
A side effect of your proposal is that if the recipient of the OAF does not
support the credit advance, that the originator of the connection will have
sacrificed 1 credit permanently for that connection since the OAF originator
has no way of knowing whether the recipient will take advantage of the
implied credit.
One way around this is to borrow from Fibre Channel and have the recipient
ignore the 1st RRDY received IF it supports the credit advance bit in the
received OAF and that bit was sent. In keeping with that, the originator of
the OAF would always send an RRDY for the advanced credit, which will be
discarded if advance is supported or otherwise used normally if advance is
not supported. This will keep the number of RRDY's consistent with the
credits in the system regardless of use of credit advance or not.
Otherwise, the rrdy's will always be 1 less, and the originator will have to
hold the credit in reserve throughout the connection. A bit of a waste.
Another, more complicated mechanism is to introduce the concept like login
credits / AL bb credit where discovery of the endpoint tells us about the
number of implied credits for new connections. I'm not in favor of that
solution.
Lastly, wish this could somehow be symentric, because clearly the one that
would benefit  the most if the originator of the OAF since we KNOW that side
has a frame to transmit.
Thoughts?
Craig



More information about the T10 mailing list