Searched hist:"3 a540664c5fbf8cabeca0c1a1af27b1b979eb253" (Results 1 – 3 of 3) sorted by relevance
| /openbmc/libmctp/ |
| H A D | libmctp.h | diff 3a540664c5fbf8cabeca0c1a1af27b1b979eb253 Tue May 26 05:25:30 CDT 2020 Andrew Jeffery <andrew@aj.id.au> astlpc: Introduce MTU negotiation
MTU negotiation is implemented in a backwards-compatible manner with
version 1 of the astlpc binding. Functionally, MTU negotation involves
proposing arrangements of the Rx and Tx buffer layouts. It is assumed
that the MTU is a packet sized to fill the Tx buffer as described in the
control space.
For v1 of the binding the MTU is defined in terms of the MCTP_BTU
constant provided by libmctp.h. MCTP_BTU is used regardless of the
buffer sizes specified in the control space (which MUST describe buffers
supporting at least MCTP_BTU-sized packets).
For v2 of the binding the MTU is defined in terms of the appropriate
buffer's size field in the control space.
The sequence of events for negotiating the MTU under v2 is as follows:
1. The BMC initialises its binding, filling out the Rx and Tx buffer
properties with the largest configuration it supports.
2. The host initialises its binding, writing its maximum Rx buffer size
before sending `channel-init` to the BMC.
3. The BMC receives `channel-init`, negotiates protocol version 2 and
then validates the host's proposed buffer configuration. If the proposed
configuration is invalid (e.g. out-of-bounds values) the BMC terminates
channel initialisation leaving the channel-active bit clear and writing
the zero to the negotiated version field. If the proposal is valid, the
BMC calculates the buffer sizes according to the available constraints
and writes the chosen buffer configuration to the control region.
4. Assuming the version negotiation and buffer configuration are
successful, the BMC sets `channel-active` and notifies the host
5. The host reads `channel-active`, accepts the negotiation of v2 and
validates the buffer configuration. If the validation passes, then the
buffer configuration is the configuration used for the remainder of the
session. If validation fails then the host MUST NOT send MCTP packets
via the LPC binding until a valid buffer configuration can be
negotiated.
Change-Id: I89107593f220418d746c2d73771348ed8f7f3e87
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| H A D | astlpc.c | diff 3a540664c5fbf8cabeca0c1a1af27b1b979eb253 Tue May 26 05:25:30 CDT 2020 Andrew Jeffery <andrew@aj.id.au> astlpc: Introduce MTU negotiation
MTU negotiation is implemented in a backwards-compatible manner with
version 1 of the astlpc binding. Functionally, MTU negotation involves
proposing arrangements of the Rx and Tx buffer layouts. It is assumed
that the MTU is a packet sized to fill the Tx buffer as described in the
control space.
For v1 of the binding the MTU is defined in terms of the MCTP_BTU
constant provided by libmctp.h. MCTP_BTU is used regardless of the
buffer sizes specified in the control space (which MUST describe buffers
supporting at least MCTP_BTU-sized packets).
For v2 of the binding the MTU is defined in terms of the appropriate
buffer's size field in the control space.
The sequence of events for negotiating the MTU under v2 is as follows:
1. The BMC initialises its binding, filling out the Rx and Tx buffer
properties with the largest configuration it supports.
2. The host initialises its binding, writing its maximum Rx buffer size
before sending `channel-init` to the BMC.
3. The BMC receives `channel-init`, negotiates protocol version 2 and
then validates the host's proposed buffer configuration. If the proposed
configuration is invalid (e.g. out-of-bounds values) the BMC terminates
channel initialisation leaving the channel-active bit clear and writing
the zero to the negotiated version field. If the proposal is valid, the
BMC calculates the buffer sizes according to the available constraints
and writes the chosen buffer configuration to the control region.
4. Assuming the version negotiation and buffer configuration are
successful, the BMC sets `channel-active` and notifies the host
5. The host reads `channel-active`, accepts the negotiation of v2 and
validates the buffer configuration. If the validation passes, then the
buffer configuration is the configuration used for the remainder of the
session. If validation fails then the host MUST NOT send MCTP packets
via the LPC binding until a valid buffer configuration can be
negotiated.
Change-Id: I89107593f220418d746c2d73771348ed8f7f3e87
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| /openbmc/libmctp/tests/ |
| H A D | test_astlpc.c | diff 3a540664c5fbf8cabeca0c1a1af27b1b979eb253 Tue May 26 05:25:30 CDT 2020 Andrew Jeffery <andrew@aj.id.au> astlpc: Introduce MTU negotiation
MTU negotiation is implemented in a backwards-compatible manner with
version 1 of the astlpc binding. Functionally, MTU negotation involves
proposing arrangements of the Rx and Tx buffer layouts. It is assumed
that the MTU is a packet sized to fill the Tx buffer as described in the
control space.
For v1 of the binding the MTU is defined in terms of the MCTP_BTU
constant provided by libmctp.h. MCTP_BTU is used regardless of the
buffer sizes specified in the control space (which MUST describe buffers
supporting at least MCTP_BTU-sized packets).
For v2 of the binding the MTU is defined in terms of the appropriate
buffer's size field in the control space.
The sequence of events for negotiating the MTU under v2 is as follows:
1. The BMC initialises its binding, filling out the Rx and Tx buffer
properties with the largest configuration it supports.
2. The host initialises its binding, writing its maximum Rx buffer size
before sending `channel-init` to the BMC.
3. The BMC receives `channel-init`, negotiates protocol version 2 and
then validates the host's proposed buffer configuration. If the proposed
configuration is invalid (e.g. out-of-bounds values) the BMC terminates
channel initialisation leaving the channel-active bit clear and writing
the zero to the negotiated version field. If the proposal is valid, the
BMC calculates the buffer sizes according to the available constraints
and writes the chosen buffer configuration to the control region.
4. Assuming the version negotiation and buffer configuration are
successful, the BMC sets `channel-active` and notifies the host
5. The host reads `channel-active`, accepts the negotiation of v2 and
validates the buffer configuration. If the validation passes, then the
buffer configuration is the configuration used for the remainder of the
session. If validation fails then the host MUST NOT send MCTP packets
via the LPC binding until a valid buffer configuration can be
negotiated.
Change-Id: I89107593f220418d746c2d73771348ed8f7f3e87
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|