Florian Westphal <fw@xxxxxxxxx> writes: > Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> So IIUC correctly, this would all be controlled by userspace anyway (by >> the nft binary), right? In which case, couldn't userspace also provide >> the reference to the right flowtable instance, by sticking it into a bpf >> map? We'd probably need some special handling on the UAPI side to insert >> a flowtable pointer, but from the BPF side it could just look like a >> kptr in a map that the program pulls out and passes to the lookup kfunc. >> And the map would take a refcnt, making sure the table doesn't disappear >> underneath the XDP program. It could even improve performance since >> there would be one less hashtable lookup. > > That requires kernel changes. Well, you started this thread with a kernel patch, so presumably we need kernel changes in any case? ;) > Not only are flowtables not refcounted at this time, we also have no > unique identifier in the uapi; only a combination (table name, family, > flowtable name, OR table name and handle id). But presumably that combination is enough to uniquely identify a table, right? So we could just use the same tuple in the map insert API. Doesn't *have* to be a numeric unique ID. And you were talking about adding refcnts anyway in your follow-up message? I'm not saying it's entirely a slam dunk, but having the reference to flowtable entries be managed out of band does add a lot of flexibility on the BPF side; in that sense it's analogous to how BPF map references are handled. > Also all of netfilter userland is network namespaced, so same keys > can exist in different net namespaces. XDP is namespaced as well, conceptually. I.e., ifindexes are used to refer to interfaces, and a device will be removed from a devmap if it is moved to a different namespace, that sort of thing. -Toke
