Subject: [forces] LFB lib 05 version comments #5

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 8 Aug 2011 19:59:21 -0400

Sorry, the last update was #4 and this is #5.

I am gonna start on section 5 as i have a lot to say there..
So i dont send huge changes - heres on sections covering 5.1.2.
Just ignore the numbering - it is for my own internal tracking.

cheers,
jamal

-----
6) Section #5
i) "already defined an ’FE Protocol LFB’ which is as a logical entity in"
to:
"already defined an ’FE Protocol LFB’ which is a logical entity in"

ii) "As specified in Section 3.1, this document focuses the base LFB"
to:
"As specified in Section 3.1, this document focuses ion the base LFB"

7) Section 5.1

i) "As the most popular physical and data link layer protocols, Ethernets
are widely deployed."

to:
"As the most popular physical and data link layer protocols, Ethernet
is widely deployed."

ii) "Note that there exist different versions of Ethernet protocols, like"
to:
 "Note that there exist different versions of Ethernet formats, like"

iii) "a base LFB definition and a start work, the document only defines an"
to:
"a base LFB definition and a starting point, the document only defines an"

8) Section 5.1.1.2
i) typo "adminstratively" - please run a spell checker

ii) The concept of AdminStatus in this LFB is equivalent to
powering off and on the PHY?

iii) "specifies whether the port is linked with an operational connector."
to:
"specifies whether the port link is operationaly up"

9) Section 5.1.1.4
change:
"This LFB is defined to be able to generate several events in which
the CE may be interested."
to:
"Several events are generated"

10) 5.1.2.1
It is odd to have an LFB port with the same name as the LFB.
Could you consider changing the name of "EtherMACIn" LFB port?

ii)"...indicating the physical port ID that the packet comes"
to:
"...indicating the physical port ID that the packet arrived on"

iii) "All Output packets are in Ethernet format, as received
from the physical layer LFB and cover all types of Ethernet packets."
to:
"All Output packets are emmited in the original ethernet format
received at the physical port, unchanged, and cover all types
of ethernet types."
iv) change last paragraph to:
"This LFB participates in ethernet flow control. This is implemented
in cooperation with EtherMACOut LFB. When the EtherMACIn LFB is overwhelmed
(XXX: does this mean there is a queue at EtherMACIn LFB?) it sets the
flow control indicator for the EtherMACOut LFB shared on the physical
port to send out an Ethernet Flow control message to the remote end".
XXX: So what happens when this LFB receives a flow control message?

v) typo "contron" - please run a spell checker.

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Aug 2011 00:26:49 +0800

Jamal,

I'l include all the editorial comments you made below and thanks so much.

On the technical comments, pls see the inline response.

thanks,
Weiming

--------------------------------------------------
From: "Jamal Hadi Salim" <[email-masked]>
Subject: [SPAM] LFB lib 05 version comments #5

> powering off and on the PHY?
Chuanhuang, pls explain this point. thanks.

> "Several events are generated"
Chuanhuang, there exist several places with this problem. I also suggest to 
change it. Pls give a detailed note on the changes that you are going to 
make on the relavent XML files and tell me so that I may make the changes in 
the description text section. thanks.

> XXX: So what happens when this LFB receives a flow control message?
Re: I'm afraid the flow control components TxFlowControl and RxFlowControl 
we defined in this LFB do not work as you mentioned as flow control 
indicators. This paragraph may need more discussions. thanks.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 11 Aug 2011 13:42:37 -0400

Hi Weiming,

Comments below:

> indicators. This paragraph may need more discussions. thanks.

Here's my understanding of the simple case on a host system:
Typically on an ethernet Network Interface - there is DMA buffer (could be
in the simple case be modelled as a queue) per MAC per direction. Modern
interfaces with virtualization etc will have more than one but thats
out of scope
here.
i.e in the simple case there will be one such buffer space for EtherMACIn
and another EtherMACOut per physical port.
Flow control to the other peer is generated when rx side (EtherMACIn)
buffers either are past certain threshold or exhausted etc.

So i think something is missing in the discussion text.
So do we need to define these queues? They should be read only I think
since i dont think they change once the device boots up.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 12 Aug 2011 09:59:07 +0800

Hi, All

>> powering off and on the PHY?
Yes.

>the description text section. thanks.
There are two places. I have made a note.
In EtherMACIn LFB:
  Input port "EtherMACIn" -> "EtherPktsIn"
In EtherMACOut LFB:
  Output port "EtherMACOut" -> "EtherPktsOut"

Yours,
Chuanhuang

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 12 Aug 2011 10:12:54 +0800

Hi,Jamal

======= 2011-08-12 01:50:03 Jamal Hadi Salim, wrote: =======
>since i dont think they change once the device boots up.

I don't think we need define the queues. The components "TxFlowControl ""RxFlowControl "
are just used for enabling/disabling flow control function. How this function will be implemented is
out of the scope of this LFB. People can use his own implementing way to reach the same result.

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 12 Aug 2011 05:14:34 -0400

> out of the scope of this LFB. People can use his own implementing way to reach the same result.

Ok, we need to say that then. So the text i sent earlier can be the following
instead.

iv) change last paragraph to:
" This LFB participates in ethernet flow control in cooperation with
EtherMACOut LFB. This document does not go into the details of
how this is implemented; the reader may refer to [someIEEE reference].
This document also does not describe how the buffers which induce the
flow control messages behave - it is assumed that such artifacts exist
and describing them is out of scope in this document".

Repeat similar text EtherMACOut etc.

I am assuming everything else i posted is ok and the authors are
working to update the document. For that reason i will post more
comments.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2011 10:57:47 +0800

I think all have been fixed based on this comment item.

thanks,
Weiming