On Thu, Nov 17, 2022 at 02:24:33AM +0200, Vladimir Oltean wrote: > Hi Maciej, > > On Thu, Nov 17, 2022 at 01:03:04AM +0100, Maciej Fijalkowski wrote: > > Hey Vladimir, > > > > have a look at xdp_convert_zc_to_xdp_frame() in net/core/xdp.c. For XDP_TX > > on ZC Rx side we basically create new xdp_frame backed by new page and > > copy the contents we had in ZC buffer. Then we give back the ZC buffer to > > XSK buff pool and new xdp_frame has to be DMA mapped to HW. > > Ah, ok, I didn't notice the xdp_convert_zc_to_xdp_frame() call inside > xdp_convert_buff_to_frame(), it's quite well hidden... > > So it's clear now from a correctness point of view, thanks for clarifying. > This could spark a separate discussion about whether there is any better > alternative to copying the RX buffer for XDP_TX and re-mapping to DMA > something that was already mapped. But I'm not interested in that, since > I believe who wrote the code probably thought about the high costs too. > Anyway, I believe that in the general case (meaning from the perspective > of the XSK API) it's perfectly fine to keep the RX buffer around for a > while, nobody forces you to copy the frame out of it for XDP_TX. I sort of agree but I will get back to you after getting some sleep. Basically I am observing better perf when I decide not to convert buff to frame for XDP_TX (in this case I'm referring to standard data path of Intel drivers, not the ZC data path). For ZC I am thinking about converting ZC Rx buff to xdp_buff, but maybe we need to revisit the idea behind that copy altogether. It was developed way before the times when XSK buffer pool got introduced.
