Native nftables dataplane #8780
Conversation
marvin-tigera
added
release-note-required
| rules = append(rules, Rule{ | ||
| Action: JumpAction{Target: failsafeChain}, | ||
| rules = append(rules, generictables.Rule{ | ||
| Match: r.NewMatch(), |
There was a problem hiding this comment.
One of the unfortunate consequences of using an interface type for the match is that leaving the Match type nil is no longer viable, as it results in nil pointer exceptions when calling bound functions where previously the function would have been called on a nil slice.
There was a problem hiding this comment.
Yeah, I was trying to think of a way around that. Probably not worth it, but you could maybe do it with generics:
type Rule[M Match, A Action] {
Match M
Action A
}
Then the rule renderer could have [M Match, A Action] too and pass them through. Would create a different kind of boilerplate everywhere! Advantage would be that the compiler would enforce getting it right.
caseydavenport
force-pushed
the
casey-nft-proto
branch
from
92b2660
to
7b2f666
Compare
There was a problem hiding this comment.
Would it make sense to rename generictables (sounds pretty generic, but it is not so much ;-) ) to say linuxtables or nettables and place both iptables and nftables below that? Now we have 3 top level tables packages, which are for linux only and one is just interfaces.
| UpdateChains([]*iptables.Chain) | ||
| RemoveChains([]*iptables.Chain) | ||
| // Table is a shim interface for generictables.Table. | ||
| type Table interface { |
There was a problem hiding this comment.
nit: What if we move this type now to generictables as say RuleChains and embed it in Table?
@tomastigera yep, I think those are both better! |
caseydavenport
force-pushed
the
casey-nft-proto
branch
2 times, most recently
from
6d4c097
to
e7f8874
Compare
caseydavenport
force-pushed
the
casey-nft-proto
branch
3 times, most recently
from
88a480e
to
02e3b17
Compare
marvin-tigera
added
release-note-required
Description
ref: #8025
Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.