[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" poi
Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" pointer.
Mon, 18 Feb 2019 10:11:13 -0700 (MST)
> The Xilinx driver does not use custom_pbufs (as suggested in
> Therefore it cannot know when a pbuf is not needed any more.
> The Xilinx driver immediately frees the DMA buffer at RX interrupt (yes,
> before LWIP has processed it).
> I know this sounds fundamentally broken, because other arriving packets
> might be overwriting the free'd DMA buffers before LWIP or the
> application had a chance to process it.
This is incorrect. What the Xilinx driver does in the rx interrupt is to
process any received data and then allocate NEW rx pbufs to any free rx
descriptors. The rx pbufs are allocated from a pool so there is no chance of
it allocating a pbuf which is currently in use.
I was suffering from a similar problem as described in the original post.
Under heavy rx load, I was seeing data corruption and started off down the
route of assuming it was something to do with cache.
What I eventually discovered is that the Xilinx driver currently hands over
control of the rx descriptors to the hardware BEFORE it has told the
descriptor where to DMA the data.
To fix the problem, move the call to XEmacPs_BdRingToHw() in xemacpsif_dma.c
so that it (and its associated status checking) is called AFTER the call to
XEmacPs_BdSetAddressRx(). Also move the dsb() so that it happens just before
I have downloaded Xilinx SDK 2018.3 and the problem is still there so I will
inform Xilinx of their error and hopefully it will be fixed in future
versions. In the meantime, move any lwip / emac code from the bsp to the
main application so you can edit it.
Sent from: http://lwip.100.n7.nabble.com/lwip-devel-f11621.html
|[Prev in Thread]
||[Next in Thread]|
- Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" pointer.,