netdev - Re: [PATCH 0/4 net-next] flow_offload: update mangle action representation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190830153351.5d5330fa@cakuba.netronome.com>
Date:   Fri, 30 Aug 2019 15:33:51 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, vishal@...lsio.com, saeedm@...lanox.com,
        jiri@...nulli.us
Subject: Re: [PATCH 0/4 net-next] flow_offload: update mangle action
 representation

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).

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..