> On Tue, Jun 29, 2021 at 5:43 AM Lorenzo Bianconi > <lorenzo.bianconi@xxxxxxxxxx> wrote: > > > > > On Mon, Jun 14, 2021 at 5:50 AM Lorenzo Bianconi <lorenzo@xxxxxxxxxx> 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 <lorenzo@xxxxxxxxxx> > > > > > > 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. Hi Alex, Reviewing the code to address this comment I think I spotted a corner case where we can't use this approach. Whenever we run dev_map_bpf_prog_run() we loose mb info converting xdp_frame to xdp_buff since xdp_convert_frame_to_buff() does not copy it and we have no xdp_rxq_info there. Do you think we should add a rxq_info there similar to what we did for cpumap? I think it is better to keep the previous approach since it seems cleaner and reusable in the future. What do you think? Regards, Lorenzo > > 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. >
Attachment:
signature.asc
Description: PGP signature
