> 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. ack, thx for pointing this out. It is clear now :) > > 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. ack > > veth_convert_skb_to_xdp_buff() tries to allocate pages, and keep > the skb fragmented. I will rework the patch using this approach. Regards, Lorenzo
Attachment:
signature.asc
Description: PGP signature
