Tariq Toukan <ttoukan.linux@xxxxxxxxx> writes: > On 21/06/2022 20:54, Andy Gospodarek wrote: >> This changes the section name for the bpf program embedded in these >> files to "xdp.frags" to allow the programs to be loaded on drivers that >> are using an MTU greater than PAGE_SIZE. Rather than directly accessing >> the buffers, the packet data is now accessed via xdp helper functions to >> provide an example for those who may need to write more complex >> programs. >> >> v2: remove new unnecessary variable >> > > Hi, > > I'm trying to understand if there are any assumptions/requirements on > the length of the xdp_buf linear part when passed to XDP multi-buf programs? > Can the linear part be empty, with all data residing in the fragments? > Is it valid? > > Per the proposed pattern below (calling bpf_xdp_load_bytes() to memcpy > packet data into a local buffer), no such assumption is required, and an > xdp_buf created by the driver with an empty linear part is valid. > > However, in the _xdp_tx_iptunnel example program, it fails (returns > XDP_DROP) in case the headers are not in the linear part. Hmm, good question! I don't think we've ever explicitly documented any assumptions one way or the other. My own mental model has certainly always assumed the first frag would continue to be the same size as in non-multi-buf packets. I do seem to recall there was some discussion around this when we were discussing whether or not we needed programs to explicitly opt-in to multi-buf support (what ended up being the "xdp.frags" section). The reason we said it might *not* be necessary to do that was that most programs would just continue working, and it would only be those that either tried to access the end of the packet, or to compute the packet length as data_end-data that would need any changes before enabling the frags flag. Which also kinda implies that headers etc would continue to be in the linear part. This is all from memory, though, so maybe others have different recollections. In any case this is probably something we should document somewhere :) -Toke
