I am making a DM8168 network test. I found when my application send UDP packets quickly ,the former 62B of the adjacent two UDP packets would be identical.
testing on Ti EVM board (21bytes of data to be sent)
(My application send 21 bytes by UDP protocol, so the size of the packet was 63B. The transmission data contains an incremented count value, and the rest of the 21B was filled with the same data.)
See the screenshot:
---The serial number of the first packet was 682 and the populated data was 0xaa.
---The serial number of the second packet must be 683 (but it became 682) and the populated data must be 0xab(but only the last byte was 0xab).
I have dump the skb data transmitted data in the EMAC driver, all the bytes were correct. But when I used wireshark to capture the packet , I found the former 62B of the adjacent two UDP packets were identical.
testing on our own board(4bytes of data to be sent)
According to the screenshot we could see the serial number of the adjacent two UDP packets were the same.
But when I dumped the skb data in the emac driver, I found this two packets were different.(different was correct)
modification:
static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct device *emac_dev = &ndev->dev;
int ret_code;
struct emac_priv *priv = netdev_priv(ndev);
/* If no link, return */
if (unlikely(!priv->link)) {
if (netif_msg_tx_err(priv) && net_ratelimit())
dev_err(emac_dev, "DaVinci EMAC: No link to transmit");
goto fail_tx;
}
FRAME_DUMP("TX:", skb->data, skb->len);
log：
TX:: len=46, bufp=0x8d807b02
00 0c 29 8a 91 6f 00 15 65 56 76 43 08 00 45 00 00 20 00 00 40 00 40 11 ... 00 0c 38 a1 33 38 31 37
RX:: len=60, bufp=0x8cd65064
22 b8 27 0f 00 0c 38 a1 33 38 31 37 00 00 00 00 00 00 00 00 00 00 00 00 ... 41 41 41 00 20 46 4a 45
TX:: len=46, bufp=0x8d807b02
00 0c 29 8a 91 6f 00 15 65 56 76 43 08 00 45 00 00 20 00 00 40 00 40 11 ... 00 0c 38 a0 33 38 31 38
We could see this two packets were different.
If I invoked the "flush_dcache_page (virt_to_page (data))" in the start_xmit function the error probability would significantly reduce. Whether it is a result of cache coherence problem?
