Re: [PATCH v5 bpf-next 01/14] xdp: introduce mb in xdp_buff/xdp_frame
From: Alexander Duyck <hidden>
Date: 2020-12-08 03:17:08
Also in:
bpf
On Mon, Dec 7, 2020 at 3:03 PM Saeed Mahameed [off-list ref] wrote:
On Mon, 2020-12-07 at 13:16 -0800, Alexander Duyck wrote:quoted
On Mon, Dec 7, 2020 at 8:36 AM Lorenzo Bianconi [off-list ref] wrote:quoted
Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer data structure in order to specify if this is a linear buffer (mb = 0) or a multi- buffer frame (mb = 1). In the latter case the shared_info area at the end of the first buffer is been properly initialized to link together subsequent buffers. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> --- include/net/xdp.h | 8 ++++++-- net/core/xdp.c | 1 + 2 files changed, 7 insertions(+), 2 deletions(-)diff --git a/include/net/xdp.h b/include/net/xdp.h index 700ad5db7f5d..70559720ff44 100644 --- a/include/net/xdp.h +++ b/include/net/xdp.h@@ -73,7 +73,8 @@ struct xdp_buff { void *data_hard_start; struct xdp_rxq_info *rxq; struct xdp_txq_info *txq; - u32 frame_sz; /* frame size to deducedata_hard_end/reserved tailroom*/ + u32 frame_sz:31; /* frame size to deduce data_hard_end/reserved tailroom*/ + u32 mb:1; /* xdp non-linear buffer */ };If we are really going to do something like this I say we should just rip a swath of bits out instead of just grabbing one. We are already cutting the size down then we should just decide on the minimum size that is acceptable and just jump to that instead of just stealing one bit at a time. It looks like we already have differences between the size here and frame_size in xdp_frame.+1quoted
If we have to steal a bit why not look at something like one of the lower 2/3 bits in rxq? You could then do the same thing using dev_rx in a similar fashion instead of stealing from a bit that is likely to be used in multiple spots and modifying like this adds extra overhead to?What do you mean in rxq ? from the pointer ?
Yeah, the pointers have a few bits that are guaranteed 0 and in my mind reusing the lower bits from a 4 or 8 byte aligned pointer would make more sense then stealing the upper bits from the size of the frame.