On 4/22/25 15:03, Mina Almasry wrote:
On Tue, Apr 22, 2025 at 1:16 AM Pavel Begunkov asml.silence@gmail.com wrote:
On 4/18/25 00:15, Mina Almasry wrote:
Later patches in the series adds TX net_iovs where there is no pp associated, so we can't rely on niov->pp->mp_ops to tell what is the type of the net_iov.
That's fine, but that needs a NULL pp check in io_uring as well, specifically in io_zcrx_recv_frag().
I think you mean this update in the code:
if (!niov->pp || niov->pp->mp_ops != &io_uring_pp_zc_ops || io_pp_to_ifq(niov->pp) != ifq) return -EFAULT;
Yes, thanks, will do.
That will work. I'm assuming that those pp-less niovs can end up in the rx path. I think it was deemed not impossible, right?
You can also move it to struct net_iov_area and check niov->owner->type instead. It's a safer choice than aliasing with struct page, there is no cost as you're loading ->owner anyway (e.g. for net_iov_virtual_addr()), and it's better in terms of normalisation / not unnecessary duplicating it, assuming we'll never have niovs of different types bound to the same struct net_iov_area.
Putting it in niov->owner->type is an alternative approach. I don't see a strong reason to go with one over the other. I'm thinking there will be fast code paths that want to know the type of the frag or skb> and don't need the owner, so it will be good to save loading another cacheline. We have more space in struct net_iov than we know what to do with anyway.
That's fine. I wouldn't say it's about space, we can grow net_iov private bits beyond the pp fields in sturct page, but it's rather about the mess from the aliasing page. The fact that it's net_iov makes it better, but I'd rather avoid any additional aliasing altogether.