On Tue, 11 Jun 2019 09:24:41 +0200, Björn Töpel wrote: > On 2019-06-11 00:24, Jakub Kicinski wrote: > > On Mon, 10 Jun 2019 18:02:29 +0200, Björn Töpel wrote: > >> Jakub, what's your thoughts on the special handling of XDP offloading? > >> Maybe it's just overkill? Just allocate space for the offloaded > >> program regardless support or not? Also, please review the > >> dev_xdp_support_offload() addition into the nfp code. > > > > I'm not a huge fan of the new approach - it adds a conditional move, > > dereference and a cache line reference to the fast path :( > > > > I think it'd be fine to allocate entries for all 3 types, but the > > potential of slowing down DRV may not be a good thing in a refactoring > > series. > > > > Note, that currently it's "only" the XDP_SKB path that's affected, but > yeah, I agree with out. And going forward, I'd like to use the netdev > xdp_prog from the Intel drivers, instead of spreading/caching it all over. > > I'll go back to the drawing board. Any suggestions on a how/where the > program should be stored in the netdev are welcome! :-) ...or maybe just > simply store the netdev_xdp flat (w/o the additional allocation step) in > net_device. Three programs and the boolean (remove the num_progs). Three progs? Are we planning to allow SKB and DRV at the same time? One prog and flags looked fairly reasonable to me. Flags can even be a u8. The offload prog can continue to live in the driver.
