On 4/22/25 15:03, Mina Almasry wrote:
On Tue, Apr 22, 2025 at 1:16 AM Pavel Begunkov <asml.silence@xxxxxxxxx> 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.
--
Pavel Begunkov
