Scaling the Number of TCP Cores
In typical software systems, the cost of opening a TCP connection is quite CPU expensive, and may take a long time because of RTT and processing times in the operating system. Therefore, most software driven systems keep a TCP connection alive “forever” rather than closing it. In software, the low costs of system RAM for storing each TCP connection’s state are not worth the CPU processing costs.
For MLE NPAP, each TCP connection which is open at the same time requires a dedicated TCP Core – which costs FPGA / ASIC resources. However, if RTT is low such as in a LAN, and with the very low costs of opening and closing a TCP connection in MLE NPAP (a few hundred FPGA clock cycles), “time sharing” TCP Cores can save a lot of FPGA resources without any negatives. Please refer to the MLE Technical Brief TB20201203 “Deterministic Networking with TSN-10/25/50/100G” for more information on “time sharing” TCP Cores.
Effects of On-Chip Routing:
Typically, FPGA routing is a key limiting factor: The more TCP Cores you instantiate, the more on-chip AXI-Stream FPGA routing congestion you will see, the harder it is to achieve timing closure. As a rule of thumb, more than 20 TCP Cores may cause FPGA routing issues (obviously depending on your FPGA device and toolchain).
Effects of TCP Bandwidth Sharing:
Hence, another option is to instantiate multiple MLE NPAP subsystems along with Ethernet switch logic between the Ethernet port and the multiple MLE NPAP instances. This relaxes the on-chip AXI-Stream FPGA routing. However, now more TCP connections share the Ethernet link’s line-rate which may cause other performance issues.
Multiple MLE NPAP Subsystems with a Separate IPv4 Addresses:
So, yet another option is to partition your TCP connections over multiple Ethernet links so one TCP connection does not “disturb” the other. Then, instantiate multiple MLE NPAP subsystems, each wired to a separate network port, with a separate IPv4 address.
Hybrid Acceleration:
If you need the best of both worlds then you can combine MLE NPAP with an on-chip Network Interface Card (NIC): The TCP/UDP/IPv4 Full Accelerator then takes care of certain TCP connections where throughput and/or low, deterministic latency is important while the many other TCP connections are processed via the standard software protocol stack without consuming chip resources. For this MLE has integrated MLE NPAP with the open-source Corundum FPGA MQNIC.