Re: [xdp-hints] Re: [PATCH bpf-next v2 6/8] mlx4: Introduce mlx4_xdp_buff wrapper for xdp_buff

Toke Høiland-Jørgensen
2022-11-28T22:12:46Z

Stanislav Fomichev <sdf@google.com> writes:

>> >> Why can't you simply have a pointer to xdp_buff in driver specific
>> >> xdp_buff container which would point to xdp_buff that is stack based (or
>> >> whatever else memory that will back it up - I am about to push a change
>> >> that makes ice driver embed xdp_buff within a struct that represents Rx
>> >> ring) for XDP path and for ZC the pointer to xdp_buff that you get from
>> >> xsk_buff_pool ? This would satisfy both sides I believe and would let us
>> >> keep the same container struct.
>> >>
>> >> struct mlx4_xdp_buff {
>> >> struct xdp_buff *xdp;
>> >> struct mlx4_cqe *cqe;
>> >> struct mlx4_en_dev *mdev;
>> >> struct mlx4_en_rx_ring *ring;
>> >> struct net_device *dev;
>> >> };
>> >
>> > Nah this won't work from kfunc POV, probably no way to retrieve the
>> > mlx4_xdp_buff based on xdp_buff ptr that needs to be used as an arg.
>> >
>> > Sorry I'll think more about it, in the meantime let's hear more voices
>> > whether we should keep Stan's original approach + modify xdp_buff_xsk or
>> > go with Toke's proposal.
>>
>> OK, so I played around with the mlx5 code a bit more, and I think the
>> "wrapping struct + cb area" can be made to work without too many ugly
>> casts; I'll send an updated version of the mlx5 patches with this
>> incorporated tomorrow, after I've run some tests...
>
> I'll probably send a v3 sometime tomorrow (PST), so maybe wait for me
> to make sure we are working on the same base?
> Or LMK if you prefer to do it differently..

OK, I'll send you my mlx5 patches off-list so you can just incorporate
those. Got stuck on some annoying build issues for the perf testing, so
will defer that until your next version, then :)

-Toke