On Sat, 31 Aug 2019 16:22:17 +0200, Pablo Neira Ayuso wrote: > On Fri, Aug 30, 2019 at 03:33:51PM -0700, Jakub Kicinski wrote: > > On Fri, 30 Aug 2019 11:07:10 +0200, Pablo Neira Ayuso wrote: > > > > > * The front-end coalesces consecutive pedit actions into one single > > > > > word, so drivers can mangle IPv6 and ethernet address fields in one > > > > > single go. > > > > > > > > You still only coalesce up to 16 bytes, no? > > > > > > You only have to rise FLOW_ACTION_MANGLE_MAXLEN coming in this patch > > > if you need more. I don't know of any packet field larger than 16 > > > bytes. If there is a use-case for this, it should be easy to rise that > > > definition. > > > > 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. Your reply makes limited amount of sense to me. Pleas read the code and what I wrote, if you think I'm asking for too much just say that, I'd accept that.
