[ovs-dev] Why "ovs-appctl dpif/dump-flows br-int" can't show match fields I add?

[Joe Stringer]

On 9 March 2017 at 04:23, Yang, Yi Y <yi.y.yang at intel.com> wrote:
> Hi, all
>
> I'm testing GTP-U header parsing by adding pure userspace support code, now I can "ovs-ofctl -Oopenflow13 add-flows" and "ovs-ofctl -Oopenflow13 dump-flows"
>
> $ sudo ovs-ofctl -Oopenflow13 dump-flows br-int
> OFPST_FLOW reply (OF1.3) (xid=0x2):
> cookie=0x0, duration=2930.079s, table=0, n_packets=4, n_bytes=432, udp,gtp_teid=1234 actions=drop
> cookie=0x0, duration=3028.156s, table=0, n_packets=22, n_bytes=2376, priority=0 actions=NORMAL
>
> I can see some packets matched and dropped, but when I use "ovs-appctl dpif/dump-flows br-int" to check this, I can't see key gtp_teid.
>
> $sudo ovs-appctl dpif/dump-flows br-int
> recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=17,frag=no), packets:1, bytes:108, used:4.137s, actions:drop
>
> Anyboby knows how I add a new key/match field in order that "ovs-appctl dpif/dump-flows" can show it correctly, I don't think I need to add netlink key for this because this is pure userspace code, I don't use kernel datapath. It'll be great if you can point out an existing match field example which is just for pure userspace.

Hi,

ovs-appctl dpctl/dump-flows calls into the common library function
dpctl_dump_flows(), which uses the dpif_flow_dump_next() API to fetch
flows. These flows are dumped from the datapath in netlink format, no
matter which datapath you use.

Even if you are purely trying out a userspace implementation for now,
then you'll still need to extend the
datapath/linux/compat/include/linux/openvswitch.h header with the
KEY_ATTR for your GTP field and handle all of the netlink marshalling
to be able to dump the flows from the datapath layer via this
mechanism.