| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Change transports to reserve the number of frame buffers they actually
need from the I/O service. Previously some I/O service clients reserved
0 buffers since they shared frame buffers with other clients, as we know
the two clients do not use the links simultaneously. This is possible
with the inline_io_service but not with a multithreaded I/O service
which queues buffer for clients before they are requested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the initialization state of SEPs is a graph-wide property,
link_stream_managers and mgmt_portals cannot rely on their private
members to determine if they can reset an SEP. Move the call to
init SEPs into the epid_allocator, and have it call into a
mgmt_portal to gain access to the SEP.
Thus, link_stream_managers only request that an epid_allocator
ensure an SEP is numbered and initialized, and they provide a path
to communicate with the SEP. The epid_allocator will ensure init
only happens once, so a stream currently running on another
link_stream_manager does not get interrupted. This could happen,
for example, if the OSTRM went to one device, and the ISTRM came
from another. In general, EPIDs should only be assigned once.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change data transports to use the mgmt_portal from the
link_stream_manager. The initialization state of a device's EPIDs
needs to be shared amongst all the SEP users. Otherwise, an RX
transport may attempt to do a full reset of the SEP while TX is
streaming (for example).
TODO: The code contained here is not sufficient to handle multiple
links that can access the same SEPs, as those would have different
link_stream_managers, and thus, different mgmt_portal instances and
views of the SEP state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transports:
Transports build on I/O service and implements flow control and
sequence number checking.
The rx streamer subclass extends the streamer implementation to connect
it to the rfnoc graph. It receives configuration values from property
propagation and configures the streamer accordingly. It also implements
the issue_stream_cmd rx_streamer API method.
Add implementation of rx streamer creation and method to connect it to
an rfnoc block.
rfnoc_graph: Cache more connection info, clarify contract
Summary of changes:
- rfnoc_graph stores more information about static connections at the
beginning. Some search algorithms are replaced by simpler lookups.
- The contract for connect() was clarified. It is required to call
connect, even for static connections.
|
| |
|
|
|
|
|
|
|
|
| |
These changes add APIs to instantiate the new transports. However,
only the control/management transport is currently implemented. It
uses the chdr_ctrl_xport.
Also update the mgmt_portal to use an ephemeral reference to the
shared transport, to indicate that it has no ownership of the
transport's memory.
|
| |
|
|
|
| |
The management looks at the transport endianness from the packet
factory to determine if the byte_swapper in the FPGA needs to be enabled
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- chdr_ctrl_endpoint can manage multiple dest EPIDs
- Moved from both_xports_t to a special defs in rfnoc_common
- Changed data-structures where appropriate
|
| |
|
|
|
|
| |
- Moved chdr_packet and chdr_types from rfnoc/chdr to rfnoc and updated
all references
- Moved non-CHDR definitions to rfnoc_common.hpp
|
|
|
- The management portal is the interface for the framework
to allow discovering the data topology, setup routes between
stream endpoints and configure streamers
- Use a zero_copy_if and the mgmt_paylod to send/recv packets
|
