The "learn" action can create matching return flows. If those have a long
timeout then it's a good idea to have a way to notice when in fact the
flows have terminated. This new action and matching "learn" feature
provides that way.
Feature #8603.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, parts of a field have been dealt with in a fairly ad-hoc way.
struct mf_subfield and the supporting functions added by this commit make
their use more systematic.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This commit switches from using the actual protocol values of error codes
internally in Open vSwitch, to using abstract values that are translated to
and from protocol values at message parsing and serialization time. I
believe that this makes the code easier to read and to write.
This is also one step along the way toward OpenFlow 1.1 support because
OpenFlow 1.1 renumbered a bunch of error codes.
Signed-off-by: Ben Pfaff <blp@nicira.com>
learn_parse() and learn_check() are supposed to apply the same checks, but
they are implemented very differently. It seems best to have learn_parse()
actually call learn_check() just to be sure.
This would have caught the bug fixed in the previous commit, because
the tests actually contain instances of "learn" actions that trigger the
bug, but the tests only parsed the actions without ever doing anything
that checked them (like sending them to ovs-vswitchd over OpenFlow).
nxm_dst_check() requires a writable field. Since NX_LEARN_DST_MATCH only
matches on a field and doesn't write to a field, use nxm_src_check() for
that case instead.
Bug #7507.
Reported-by: Michael Mao <mmao@nicira.com>
There are a few loose ends here. First, learning actions cause too much
flow revalidation. Upcoming commits will fix that problem. The following
additional issues have not yet been addressed:
* Resource limits: nothing yet limits the maximum number of flows that
can be learned. It is possible to exhaust all system memory.
* Age reporting: there is no way to find out how soon a learned table
entry is due to be evicted.
To try this action out, here's a recipe for a very simple-minded MAC
learning switch. It uses a 10-second MAC expiration time to make it easier
to see what's going on:
ovs-vsctl del-controller br0
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \
NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
output:NXM_OF_IN_PORT[]), resubmit(,1)"
ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
You can then dump the MAC learning table with:
ovs-ofctl dump-flows br0 table=1
