Improvement of RTL8139 driver under VxWorks system

Introduction

RTL8139 is a fast Ethernet controller produced by Realtek Semiconductor Co., Ltd. in Taiwan. It provides an interface that complies with the PCI2.2 standard, is compatible with the IEEE802.3u 100BASE-T specification, supports IEEE-802.3x full-duplex flow control, supports 10Mbit.s-1/100Mbit.s-1 full-duplex and half-duplex self-adaptation, is cheap, has stable performance, and is one of the most widely used Ethernet controllers in PCs and telecommunications terminal products. The drivers of RTL8139 under various operating systems can be downloaded from the Realtek website, including the drivers under the VxWorks system, and C source code is provided. However, in embedded systems, for different hardware platforms, it is often necessary to modify the driver to improve its stability and efficiency. Based on the hardware platform of MPC8241 CPU, this paper proposes improvement measures for the driver of RTL8139 under the VxWorks system.

1 Introduction to the hardware platform

Figure 1 shows a partial hardware block diagram of a switch terminal device.

The CPU uses the MPC8241, one of the PowerPC series processors of Motorola. In addition to the embedded 32-bit PowerPC processor core, the chip also integrates the MPC107 bridge, providing a PCI interface to connect with the RTL8139. There is a memory controller on the bridge, with 16MB SDRAM and 4 MBFlash. The CPU clock is 166MHz, the SDRAM clock is 66MHz, and the PCI clock is 33MHz. The RTL8139 works at 10Mbit/s, half-duplex mode, and is connected to the Internet through a hub. Its function is to forward data packets composed of voice signals, requiring 1200pps (data packets per second), and the CPU occupancy rate is not higher than 50%.

VxWorks supports Ethernet controller drivers in END (Added Network Driver) format, and provides a MUX layer as the interface between the network protocol and the Ethernet controller driver. MUX specifies the interface functions of the driver. The RTL8139 driver Rtl8139End.c is a code written completely in END format, providing all the interface functions specified by the MUX layer. As long as the RTL8139 PCI configuration space register is written, the PCI space first address, interrupt vector number and interrupt priority parameters are passed in sysRtl8139End.c, and the driver loader is driven in END format, RTL8139 can run smoothly after successful loading.

2 Problems to be solved in the driver

If the sending and receiving rate of data packets is uniform, RTL8139 can fully meet the requirements mentioned above, but there are often bursts of data packets on the Internet, and the receiving FIFO and sending FIFO of RTL8139 are only 2Kb. In addition, RTL8139 adopts a complete copy method for sending and receiving data packets. During the burst of data packets, the CPU occupancy rate is too high, and there is no time to process too many data packets, resulting in packet loss. In Rtl8139End.c, the driver's packet buffer and the protocol stack's memory pool are completely separate. There is a copy process for both packet reception and transmission, while high-performance Ethernet controllers generally only need to copy once when sending. In this way, the CPU needs to copy once more for each packet received and sent. This is an important reason for the low performance of RTL8139. However, this packet processing method is determined by hardware and cannot be changed by the driver. In fact, in the case of a large number of burst packets, it is allowed for the Ethernet controller to lose packets, but after the burst time, the normal packet receiving and sending process should be restored. However, when running Rtl8139End.c on the hardware platform introduced in the previous article, a Sniffer is used on the PC to continuously send packets to RTL8139. The test time is tens of seconds. After stopping the packet sending, the ping command is used on the PC to test whether RTL8139 can return packets normally. The result is that it cannot be pinged through, indicating that the packet receiving and sending process of RTL8139 is interrupted due to too many burst packets and cannot be restored.

Analyzing the Rtl8139End.c program, its packet sending process is shown in Figure 2.

[page]

RTL8139 has 4 transmit descriptors, each with its own transmit status registers TSD0~TSD3 and transmit start address registers TSAD0~TSAD3. Each transmit descriptor can send 1 data packet. In the function Rtl8139Send(), apply for 1 transmit data packet buffer, copy the data packet passed down by the protocol stack into the buffer, then write the first address of the buffer into the transmit start address register, and finally fill in the transmit status register, and set its OWN position to 0, indicating that the buffer is handed over to the transmit DMA management of RTL8139 and the transmit operation is started. After the transmission is completed, RTL8139 generates an interrupt, enters the interrupt service routine Rtl8139Int(), calls Rtl8139HandleSendInt(), and reads the transmit status register in this function. If the OWN bit is 1, it means that the transmit DMA operation is completed and the corresponding transmit buffer is released; otherwise, it means that the transmit DMA operation is not completed, and the transmit buffer is still owned by the RTL8139 hardware. Check the OWN bit again when entering the transmit interrupt next time. This cycle repeats until the OWN bit becomes 1, and then the corresponding send buffer can be released, and the send descriptor it occupies becomes available.

The above process can be summarized into two points:

a) Apply for a data packet buffer in Rtl8139Send() and occupy a send descriptor;

b) Release the corresponding data packet buffer and send descriptor in Rtl8139Int().

From the above analysis, it can be seen that as long as there is no problem in these two links of packet sending, the packet sending process will not be interrupted. In addition, in Rtl8139HandleSendInt(), not only one packet buffer and descriptor are released, but all descriptors and corresponding packet buffers that have started the packet sending operation and the OWN bit of the send status register becomes 1 are released. This can enhance the stability of the program. In the case of burst packets, the CPU may not have time to respond to the interrupt, that is, the interrupt is lost, but as long as there is still one descriptor available, the interrupt can be entered after the packet sending is completed, and all the previously occupied buffers and descriptors can be released. If there are too many burst packets, the CPU does not respond to four consecutive packet interrupts, and all the send descriptors are occupied. The next time Rtl8139Send() is entered, there will be no send descriptors available, and there will be no more packet interrupts. Rtl8139HandleSendInt() will not be called, and the send descriptors cannot be released. The packet sending process is interrupted and cannot be restored. This is why the above RTL8139 cannot be pinged.

3 Solution

According to the above analysis, the packet sending process can only be restored by releasing the occupied send descriptors and send buffers, which can be achieved by calling Rtl8139HandleSendInt() once. MPC8241 has 4 timers (TimerO~Timer3) integrated in the chip, and TimerO can be used to generate hardware timing interrupts. In the interrupt service program, netJobAdd() is called with the Rtl8139HandleSendInt function pointer as the entry parameter, so that Rtl8139HandleSendInt() can be executed regularly to release the occupied send descriptors in time. This requires adding the following code to Rtl8139Start():

Among them: (pDrvCtrl->TxRingFree<0) means there is no idle transmit descriptor.

The modified driver is tested again using the method described in the previous article. After the Sniffer stops sending packets, RTL8139 can recover. Using Smartbit test, send packets to RTL8139 at half-duplex and 10 Mbit/s line speed. After the packet stops sending, RTL8139 can still recover. Use Smartbit to send packets to RTL8139 at a uniform rate of 1 200pps, with a packet length of 240 bytes. The test results are: RTL8139 does not lose packets, and the CPU occupancy rate is 45%.

4 Conclusion

The method introduced in this article can effectively enhance the robustness of the program without reducing efficiency. It runs stably for a long time on the switch terminal, and the performance fully meets the requirements.