| commit | 4df106db7766a56d6db67556b0072295c2d5659d | [log] [tgz] |
|---|---|---|
| author | Frederic Barrat <fbarrat@linux.ibm.com> | Tue May 16 17:45:42 2023 +0200 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Mon May 22 01:18:42 2023 +0000 |
| tree | 01d23f02101564659b3126ea7cdc97d3df1b7dad | |
| parent | 7f7fdc1dcb9b9f6eeabc27e76321f3584e031148 [diff] |
astlpc: Add mctp_astlpc_tx_done() API
Add the mctp_astlpc_tx_done() API to help with packet transfer
performance when using the LPC binding with the Aspeed BMC. The goal
of the API is to tell the caller that the Transmit buffer has been
consumed by the remote side, i.e. the Rx_complete command has been
received locally. It can be helpful on the host side because of the
way the Aspeed BMC implements the KCS devices.
The Aspeed BMC's KCS device doesn't provide an interrupt when the ODR
register is read by the remote client/host. To workaround it, the
linux KCS driver for Aspeed arms a timer to periodically check (every
0.5 second in the current implementation) the state of the register
and generate an "Output Buffer Empty" (OBE) event to wake up any
client on the BMC, for example the mctp-demux-daemon.
Typically, the mctp-demux-daemon waits in the poll() system call and
wakes up when it receives a packet. When it's coming from the LPC bus
and KCS device, the remote writes a Tx_begin command in the IDR
register, which does generate an interrupt. To acknowledge the packet,
the mctp-demux-daemon writes a Tx_complete command in the ODR and can
then dispatch the request to the proper recipient (i.e. the PLDM
daemon). When it wants to send a message on the LPC bus, the
mctp-demux-daemon needs to wait till the ODR register has been read by
the remote. Because we don't have an interrupt to know when that
happens, the mctp-demux-daemon waits in poll() and will be awaken when
an OBE event is generated by a background thread processing the timer
interrupt. So when the mctp-demux-daemon enters poll() with something
to send on the LPC bus, if the ODR is not available immediately, it
will only be sent after the timer fires. Which could take up to 0.5s
with the current driver implementation.
So when the host sends a PLDM request, it is therefore crucial, for
good performance, that it reads the Rx_complete command out of the ODR
very quickly when it's sending a MCTP packet as to free it and make
sure the mctp-demux-daemon can send the reply immediately instead of
having to wait in poll(). That's where the new mctp_astlpc_tx_done()
helps: immediately after sending a message, the host can call
repeatedly mctp_astlpc_poll() to read the KCS device status and read
the ODR as fast as possible and with the mctp_astlpc_tx_done() API, it
knows when to stop. Pseudo code looks like this (ignoring that we
should timeout out of the loop after a while):
mctp_message_tx()
while (!mctp_astlpc_tx_done(astlpc)) {
mctp_astlpc_poll(astlpc);
}
Note that the API, while generic, is (so far) only useful when called
from a remote LPC endpoint.
Change-Id: I5e6d62aa142fe97449ccf9c9a2ade3cf45d02bf6
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
This library is intended to be a portable implementation of the Management Component Transport Protocol (MCTP), as defined by DMTF standard "DSP0236", plus transport binding specifications.
The APIs and ABI of libmctp are not yet stablised as we continue to explore ways to present the MCTP protocol to firmware and applications. Please bear with us!
When we approach a complete implementation of DSP0236 we will consider the suitability of the API/ABI for stabilisation.
In the mean time, we'd like your feedback on the library's suitability for your environment.
To initialise the MCTP stack with a single hardware bus:
mctp = mctp_init(): Initialise the MCTP corebinding = mctp_<binding>_init(): Initialise a hardware bindingmctp_register_bus(mctp, binding, eid): Register the hardware binding with the core, using a predefined EIDThen, register a function call to be invoked when a message is received:
mctp_set_rx_all(mctp, function): Provide a callback to be invoked when a MCTP message is receivedOr transmit a message:
mctp_message_tx(mctp, message, len): Transmit a MCTP messageThe binding may require you to notify it to receive packets. For example, for the serial binding, the mctp_serial_read() function should be invoked when the file-descriptor for the serial device has data available.
libmctp implements basic support for bridging between two hardware bindings. In this mode, bindings may have different MTUs, so packets are reassembled into their messages, then the messages are re-packetised for the outgoing binding.
For bridging between two endpoints, use the mctp_bridge_busses() function:
mctp = mctp_init(): Initialise the MCTP coreb1 = mctp_<binding>_init(); b2 = mctp_<binding>_init(): Initialise two hardware bindingsmctp_bridge_busses(mctp, b1, b2): Setup bridgeNote that no EIDs are defined here; the bridge does not deliver any messages to a local rx callback, and messages are bridged as-is.
Hardware bindings provide a method for libmctp to send and receive packets to/from hardware. A binding defines a hardware specific structure (struct mctp_binding_<name>), which wraps the generic binding (struct mctp_binding):
struct mctp_binding_foo {
struct mctp_binding binding;
/* hardware-specific members here... */
};
The binding code then provides a method (_init) to allocate and initialise the binding; this may be of any prototype (calling code will know what arguments to pass):
struct mctp_binding_foo *mctp_binding_foo_init(void);
or maybe the foo binding needs a path argument:
struct mctp_binding_foo *mctp_binding_foo_init(const char *path);
The binding then needs to provide a function (_core) to convert the hardware-specific struct to the libmctp generic core struct
struct mctp_binding *mctp_binding_foo_core(struct mctp_binding_foo *b);
(Implementations of this will usually be fairly consistent, just returning b->binding). Callers can then use that generic pointer to register the binding with the core:
struct mctp_binding *binding = mctp_binding_foo_core(foo); mctp_register_bus(mctp, binding, 8);
The libmctp code is intended to be integrated into other codebases by two methods:
as a simple library (libmctp.{a,so}) which can be compiled separately and linked into the containing project
as a set of sources to be included into the containing project (either imported, or as a git subtree/submodule)
For (1), you can use the top-level makefile to produce libmctp.a.
For (2), the Makefile.inc file provides the minimum set of dependencies to either build libmctp.a, or just the actual object files (LIBMCTP_OBS), which you can include into your existing make definitions. You'll want to set LIBMTCP_DIR to refer to the subdirectory that contains that makefile, so we can set the correct paths to sources.
This library is intended to be portable to be used in a range of environments, but the main targets are:
For the latter, we need to support customisation of the functions that libmctp uses (for example, POSIX file IO is not available).
In order to support these, we have a few compile-time definitions:
MCTP_HAVE_FILEIO: define if POSIX file io is available, allowing the serial hardware binding to access char devices for IO.
MCTP_HAVE_SYSLOG: allow logging to syslog, through the vsyslog call.
MCTP_DEFAULT_ALLOC: set default allocator functions (malloc, free, realloc), so that applications do not have to provide their own.