On Wed, Aug 03, 2022 at 04:25:40PM -0700, Jakub Kicinski wrote: > The point of skb_header_pointer() is to expose the chunk of the packet > pointed to by [skb, offset, len] as a linear buffer. Potentially coping > it out to a stack buffer *IIF* the header is not contiguous inside the > skb head, which should very rarely happen. > > Here it seems we return an error so that user must pull if the data is > not linear, which is defeating the purpose. The user of > skb_header_pointer() wants to avoid the copy while _reliably_ getting > a contiguous pointer. Plus pulling in the header may be far more > expensive than a small copy to the stack. > > The pointer returned by skb_header_pointer is writable, but it's not > guaranteed that the writes go to the packet, they may go to the > on-stack buffer, so the caller must do some sort of: > > if (data_ptr == stack_buf) > skb_store_bits(...); > > Which we were thinking of wrapping in some sort of flush operation. Curious on the idea. don't know whether this is a dynptr helper or should be a specific pkt helper though. The idea is to have the prog keeps writing to a ptr (skb->data or stack_buf). When the prog is done, call a bpf helper to flush. The helper decides if it needs to flush from stack_buf to skb and will take care of the cloned skb ? > > If I'm reading this right dynptr as implemented here do not provide > such semantics, am I confused in thinking that this is a continuation > of the XDP multi-buff discussion? Is it a completely separate thing > and we'll still need a header_pointer like helper? Can you share a pointer to the XDP multi-buff discussion?
