On Sun, Sep 01, 2019 at 01:47:54PM -0700, Jakub Kicinski wrote: > On Sat, 31 Aug 2019 16:22:17 +0200, Pablo Neira Ayuso wrote: [...] > > > Please see the definitions of: > > > > > > struct nfp_fl_set_eth > > > struct nfp_fl_set_ip4_addrs > > > struct nfp_fl_set_ip4_ttl_tos > > > struct nfp_fl_set_ipv6_tc_hl_fl > > > struct nfp_fl_set_ipv6_addr > > > struct nfp_fl_set_tport > > > > > > These are the programming primitives for header rewrites in the NFP. > > > Since each of those contains more than just one field, we'll have to > > > keep all the field coalescing logic in the driver, even if you coalesce > > > while fields (i.e. IPv6 addresses). > > > > nfp has been updated in this patch series to deal with the new mangle > > representation. > > It has been updated to handle the trivial coalescing. > > > > Perhaps it's not a serious blocker for the series, but it'd be nice if > > > rewrite action grouping was handled in the core. Since you're already > > > poking at that code.. > > > > Rewrite action grouping is already handled from the core front-end in > > this patch series. > > If you did what I'm asking the functions nfp_fl_check_mangle_start() > and nfp_fl_check_mangle_end() would no longer exist. They were not > really needed before you "common flow API" changes. Thanks for the pointer. This driver-level coalescing routine you are refering to is specific to optimize your layout. I agree the core could be updated to do more coalescing, but this would need a way to express what coalescing the driver would like to see in place. I would wait to see more drivers that can benefit from that. I can only make incremental steps, it's already hard to navigate over all this code.
