From: Pablo Neira Ayuso <firstname.lastname@example.org> To: Edward Cree <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation Date: Fri, 6 Sep 2019 15:14:57 +0200 Message-ID: <20190906131457.7olkal45kkdtbevo@salvia> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, Sep 06, 2019 at 01:55:29PM +0100, Edward Cree wrote: > On 06/09/2019 11:56, Pablo Neira Ayuso wrote: > > On Fri, Sep 06, 2019 at 11:02:18AM +0100, Edward Cree wrote: > >> Still NAK for the same reasons as three versions ago (when it was called > >> "netfilter: payload mangling offload support"), you've never managed to > >> explain why this extra API complexity is useful. (Reducing LOC does not > >> mean you've reduced complexity.) > > Oh well... > > > > Patch 1) Mask is inverted for no reason, just because tc pedit needs > > this in this way. All drivers reverse this mask. > > > > Patch 2) All drivers mask out meaningless fields in the value field. > > To be clear: I have no issue with these two patches; they look fine to me. > (Though I'd like to see some comments on struct flow_action_entry specifying > the semantics of these fields, especially if they're going to differ from > the corresponding fields in struct tc_pedit_key.) OK, I can document this semantics, I need just _time_ to write that documentation. I was expecting this patch description is enough by now until I can get to finish that documentation. > > Patch 3) Without this patchset, offsets are on the 32-bit boundary. > > Drivers need to play with the 32-bit mask to infer what field they are > > supposed to mangle... eg. with 32-bit offset alignment, checking if > > the use want to alter the ttl/hop_limit need for helper structures to > > check the 32-bit mask. Mangling a IPv6 address comes with one single > > action... > > Drivers are still going to need to handle multiple pedit actions, in > case the original rule wanted to mangle two non-consecutive fields. > And you can't just coalesce all consecutive mangles, because if you > mangle two consecutive fields (e.g. UDP sport and dport) the driver > still needs to disentangle that if it works on a 'fields' (rather > than 'u32s') level. This infrastructure is _not_ coalescing two consecutive field, e.g. UDP sport and dport is _not_ coalesced. The coalesce routine does _not_ handle multiple tc pedit ex actions. I'll clarify this in the cover letter in the next patchset round. > So either have the core convert things into named protocol fields > (i.e. "set src IPv6 to 1234::5 and add 1 to UDP sport"), or leave > the current sequence-of-u32-mangles as it is. This in-between "we'll > coalesce things together despite not knowing what fields they are" is > neither fish nor fowl. The model you propose would still need this code for tc pedit to adjust offset/length and coalesce u32 fields.
next prev parent reply index Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-06 0:03 Pablo Neira Ayuso 2019-09-06 0:04 ` [PATCH net-next,v3 1/4] net: flow_offload: flip mangle action mask Pablo Neira Ayuso 2019-09-06 0:04 ` [PATCH net-next,v3 2/4] net: flow_offload: bitwise AND on mangle action value field Pablo Neira Ayuso 2019-09-06 0:04 ` [PATCH net-next,v3 3/4] net: flow_offload: mangle action at byte level Pablo Neira Ayuso 2019-09-06 0:04 ` [PATCH net-next,v3 4/4] netfilter: nft_payload: packet mangling offload support Pablo Neira Ayuso 2019-09-06 10:02 ` [PATCH net-next,v3 0/4] flow_offload: update mangle action representation Edward Cree 2019-09-06 10:56 ` Pablo Neira Ayuso 2019-09-06 12:55 ` Edward Cree 2019-09-06 13:14 ` Pablo Neira Ayuso [this message] 2019-09-06 13:37 ` Edward Cree 2019-09-06 14:50 ` Pablo Neira Ayuso 2019-09-06 15:13 ` Edward Cree 2019-09-06 15:58 ` Pablo Neira Ayuso 2019-09-06 16:49 ` Edward Cree 2019-09-06 18:15 ` Pablo Neira Ayuso
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190906131457.7olkal45kkdtbevo@salvia \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Netfilter-Devel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/netfilter-devel/0 netfilter-devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 netfilter-devel netfilter-devel/ https://lore.kernel.org/netfilter-devel \ email@example.com public-inbox-index netfilter-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.netfilter-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git