On Tue, 28 Nov 2023 23:27:29 +0100 Lorenzo Bianconi wrote: > > Yes, don't we allow writes to fragments in XDP based on the assumption > > that it runs on Rx so that paged data must not be zero copy? > > bpf_xdp_store_bytes() doesn't seem to have any checks which would > > stop it from writing fragments, as far as I can see. > > do you mean in the skb use-case we could write to fragments (without copying > them) if the skb is not cloned and the paged area is not 'zero-copied'? The zero-copy thing is a red herring. If application uses sendpage/sendfile/splice the frag may be a page cache page of a file. Or something completely read only. IIUC you're trying to avoid the copy if the prog is mbuf capable. So I was saying that can't work for forms of XDP which actually deal with skbs. But that wasn't really your question, sorry :) > With respect to this patch it would mean we can rely on pskb_expand_head() to > reallocate the skb and to covert it to a xdp_buff and we do not need to explicitly > reallocate fragments as we currently do for veth in veth_convert_skb_to_xdp_buff() [0]. > Is my understanding correct or am I missing something? The difference is that pskb_expand_head() will give you a linear skb, potentially triggering an order 5 allocation. Expensive and likely to fail under memory pressure. veth_convert_skb_to_xdp_buff() tries to allocate pages, and keep the skb fragmented.
