> On Tue, Jun 29, 2021 at 5:43 AM Lorenzo Bianconi > wrote: > > > > > On Mon, Jun 14, 2021 at 5:50 AM Lorenzo Bianconi wrote: > > > > > > > > Introduce flags field in xdp_frame/xdp_buffer data structure > > > > to define additional buffer features. At the moment the only > > > > supported buffer feature is multi-buffer bit (mb). Multi-buffer bit > > > > is used 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 will be properly initialized to link together > > > > subsequent buffers. > > > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > Instead of passing this between buffers and frames I wonder if this > > > wouldn't be better to place in something like the xdp_mem_info > > > structure since this is something that would be specific to how the > > > device is handling memory anyway. You could probably split the type > > > field into a 16b type and a 16b flags field. Then add your bit where 0 > > > is linear/legacy and 1 is scatter-gather/multi-buffer. > > > > > > > ack, this should be fine but I put the flag field in xdp_buff/xdp_frame > > in order to reuse it for some xdp hw-hints (e.g rx checksum type). > > We can put it in xdp_mem_info too but I guess it would be less intuitive, what > > do you think? > > I think it makes the most sense in xdp_mem_info. It already tells us > what to expect in some respect in regards to memory layout as it tells > us if we are dealing with shared pages or whole pages and how to > recycle them. I would think that applies almost identically to > scatter-gather XDP the same way. > > As far as the addition of flags there is still time for that later as > we still have the 32b of unused space after frame_sz. ack, I am fine with it. If everybody agree, I will fix it in v10. Regards, Lorenzo >