On Fri, 14 Jun 2019 13:25:28 +0000, Maxim Mikityanskiy wrote: > On 2019-06-13 20:29, Jakub Kicinski wrote: > > On Thu, 13 Jun 2019 14:01:39 +0000, Maxim Mikityanskiy wrote: > > > > Yes, okay, I get that. But I still don't know what's the exact use you > > have for AF_XDP buffers being 4k.. Could you point us in the code to > > the place which relies on all buffers being 4k in any XDP scenario? Okay, I still don't get it, but that's for explaining :) Perhaps it will become clearer when you resping with patch 17 split into reviewable chunks :) > 1. An XDP program is set on all queues, so to support non-4k AF_XDP > frames, we would also need to support multiple-packet-per-page XDP for > regular queues. Mm.. do you have some materials of how the mlx5 DMA/RX works? I'd think that if you do single packet per buffer as long as all packets are guaranteed to fit in the buffer (based on MRU) the HW shouldn't care what the size of the buffer is. > 2. Page allocation in mlx5e perfectly fits page-sized XDP frames. Some > examples in the code are: > > 2.1. mlx5e_free_rx_mpwqe calls a generic mlx5e_page_release to release > the pages of a MPWQE (multi-packet work queue element), which is > implemented as xsk_umem_fq_reuse for the case of XSK. We avoid extra > overhead by using the fact that packet == page. > > 2.2. mlx5e_free_xdpsq_desc performs cleanup after XDP transmits. In case > of XDP_TX, we can free/recycle the pages without having a refcount > overhead, by using the fact that packet == page.
