On Wed, Nov 28, 2018 at 01:51:42PM -0500, Aaron Conole wrote: > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > > On Tue, Nov 27, 2018 at 09:24:05AM -0500, Aaron Conole wrote: > >> > >> 1. Introduce flowmap again, this time, basically having it close to a > >> copy of the hashmap. Introduce a few function calls that allow an > >> external module to easily manipulate all maps of that type to insert > >> / remove / update entries. This makes it similar to, for example, > >> devmap. > > > > what is a flowmap? > > How is this flowmap different from existing hash, lpm and lru maps? > > The biggest difference is how relationship works. Normal map would > have single key and single value. Flow map needs to have two keys > "single-value," because there are two sets of flow tuples to track > (forward and reverse direction). That means that when updating the k-v > pairs, we need to ensure that the data is always consistent and up to > date. Probably we could do that with the existing maps if we had some > kind of allocation mechanism, too (so, keep a pointer to data from two > keys - not sure if there's a way to do that in ebpf)? just swap the src/dst ips inside bpf program depending on direction and use the same hash map. That's what xdp/bpf users already do pretty successfully. bpf hash map is already offloaded into hw too. > forward direction addresses could be different from reverse direction so > just swapping addresses / ports will not match). That makes no sense to me. What would be an example of such flow? Certainly not a tcp flow. > That lets us use xdp as a fast forwarding path for > connections, getting all of the advantage of helper modules to do the > control / parsing, and all the advantage of xdp for packet movement. >From 10k feet view it sounds correct, but details make no sense. You're saying doing nat in the stack, but that _is_ the packet movement where you wanted to use xdp.
