Sorry for resending, but an earlier version of the message was blocked
by list filters:
Hi,
When testing the OVS datapath in the context of work on L3 tunneling and
packet-type aware pipeline, we have observed that ofproto-dpif-xlate
unwildcards match fields that are being modified by set_field actions,
even when those fields are never matched on in the pipeline.
As a result the megaflow cache is bloated with unnecessarily many
entries that only differ in such a non-matched field and the datapath
classifier lookup cost increases due to larger miniflow keys/masks.
Example:
OpenFlow flow entry:
ovs-ofctl -Oopenflow13 add-flow br0
“in_port=2,actions=set_field:fe:4a:7a:ae:7c:fb->dl_dst,1”
Datapath flows:
recirc_id(0),in_port(3),eth(dst=fe:4a:7a:ae:7c:f1),eth_type(0x0800),ipv4(frag=no),
packets:26, bytes:2548, used:0.571s,
actions:set(eth(dst=fe:4a:7a:ae:7c:fb)),2
recirc_id(0),in_port(3),eth(dst=fe:4a:7a:ae:7c:f2),eth_type(0x0800),ipv4(frag=no),
packets:26, bytes:2548, used:0.571s,
actions:set(eth(dst=fe:4a:7a:ae:7c:fb)),2
recirc_id(0),in_port(3),eth(dst=fe:4a:7a:ae:7c:f3),eth_type(0x0800),ipv4(frag=no),
packets:26, bytes:2548, used:0.571s,
actions:set(eth(dst=fe:4a:7a:ae:7c:fb)),2
…
We do not understand why this is done and, if there are no good reasons
to keep it, would suggest to remove the unwildcarding of fields modified
by set_field actions.
What we do understand is that fields are unwildcarded when they are
copied into packet registers or other packet fields. The reason is that
these do/may affect the resulting packet. But that is not the case here.
In the context of L3 tunneling and PTAP the current behavior produces
incorrect results because setting the dl_dst of a packet received from
an L3 port adds a match on dl_dst==00:00:00:00:00:00 to the Megaflow
which can never match because the packet received from the L3 tunnel
does not have a dl_dst field.
Thanks, Jan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
