Part Number: TDA4VM
Tool/software:
TDA4VM: SDK8.4
Hi,Ti,
We are planning to use the port mirroring feature of cpsw9g. But since there are no examples, I can only try to configure the feature using the Enet_ioctl (CPSW_ALE_IOCTL_SRT_PORT_MIRROR_CFG) reserved by the SDK. We were pleasantly surprised to find that port mirroring feature can be achieved.
However, we still encountered a problem: when the receiving macport of the image is linkdown (or if there are no devices receiving the traffic), TDA4 will soon be unable to send out packets through any mac_port port (≈ 3s). If we connect the collecting device cable properly at this point, not only can the collection device receive the mirrored traffic, but the network functions of other macports of TDA4 will also immediately return to normal. Then if we disconnect the collecting device cable this time, the network function of TDA4 will be abnormal again. It has strong real-time performance...
Here is our network topology:
We want to mirror the traffic “”entering mac_port 3 + entering mac_port 6 + emitted by mac_port 6 ” to mac_port 5. So my mirror config is:
CpswAle_PortMirroringCfg portMirrorInArgs; portMirrorInArgs.matchEn = false; portMirrorInArgs.toPortNum = Macport5; portMirrorInArgs.srcEn = true; portMirrorInArgs.srcPortNumMask = Macport3Mask|Macport6Mask portMirrorInArgs.dstEnEn = true; portMirrorInArgs.dstPortNum = Macport6; Enet_ioctl(hEnet,coreId,CPSW_ALE_IOCTL_SRT_PORT_MIRROR_CFG, portMirrorInArgs);
After powering on，if the collecting device is link up, then device(192.168.3.71) can ping A72 success; If the collecting device is link down, then device(192.168.3.71) whil ping A72 failed.
When collecting statistical data of cpsw, I found that the three arp requests I sent directly caused the param "rx_top_of_fifo_drop" of Macport3 increase by three. But at the same time on A72, i get all the three arp requests by tcpdump, but i dont get any arp response by tcpdump, which was very strange.
Furthermore, since the link up/down status of mac_port5&phy will affect the network performance when the MIrroring is turn on, I have examined which registers will be changed by phy link down. Finally I found that the GMII_EN (bit5) of the register CPSW_PN_MAC_CONTROL_REG_k played a decisive role.
In the above Mirroring enabled situation, if the collecting device is link up, the register CPSW_PN_MAC_CONTROL_REG_k will be set to 0x000200A1 by driver, then if i write it to 0x00020081 manually , the fault will occur.
On the contrary, even if the collecting device is link down. As long as I configure the register to GMII_EN Enable, the network will be restored.
So maybe you can explain this phenomenon.
Since GMII_EN is control by driver, it reflects the connection status of GMII, we'd better not proactively modify it. But in the case of GMII disabled, Mirroring will cause malfunctions, so should we have to open/close MIrroring when macport5 got_link or lost_link?
Best Regards.
