On 4 February 2015 at 16:31, Ankur Sharma <ankursha...@vmware.com> wrote:
> <snip>
> @@ -103,7 +103,9 @@ const NL_POLICY nlFlowPolicy[] = {
> .maxLen = sizeof(struct ovs_flow_stats),
> .optional = TRUE},
> [OVS_FLOW_ATTR_TCP_FLAGS] = {NL_A_U8, .optional = TRUE},
> - [OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE}
> + [OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE},
> + [OVS_FLOW_ATTR_UFID] = { .type = NL_A_UNSPEC, .optional = TRUE,
> + .minLen = sizeof(OvsU128) }
> };
>
> [ANKUR]: As nithin correctly, mentioned what we are trying to do with
> OVS_FLOW_ATTR_UFID is not clear? Do we not want to support it or do we want
> it to be a NO OP? If we want it to be a NO OP then is it going to create some
> functionality issue (since we'll end up returning success to user space while
> kernel did not do anything)
See check_ufid(), dpif_feature_probe() in userspace. If the kernel
silently ignores the UFID attribute during the feature probe, then
userspace should detect that and disable the UFID feature. After that,
no UFID should be sent to the kernel.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
