I recall someone mentioning on this list that the only planned use for skb_mark
is for ipsec tunneling. At least currently this seems to be the case, as the
only place where the skb_mark is set to a potentially non-zero value in
userspace is in tnl_port_send(). The kernel datapath may also provide a
non-zero skb_mark via odp_flow_key_to_flow().
Also, we say in ofputil_usable_protocols():
/* skb_mark and skb_priority can't be sent in a flow_mod */
if (wc->masks.skb_mark || wc->masks.skb_priority) {
return OFPUTIL_P_NONE;
}
which is consistent with the tunneling-only use.
Also, I believe that "skb_mark" is specific to Linux kernel datapath, and other
datapath types should somehow emulate it to implement compatible IPSEC
tunneling, knowing that it can only take values of 0 and 1 and that the value 1
together with a tunnel action signals the intention to use an IPSEC tunnel in
the next output action.
If this is the case, wouldn't it be better to replace the skb_mark in the
userspace struct flow with an IPSEC flag in the struct flow_tnl? This would
also shrink the struct flow, as there is compiler provided padding available at
the end of struct flow_tnl.
On the same note, I believe the skb_priority in struct flow should be renamed
as "qos_priority" ("priority" alone might be confused with the concept of OF
flow priority). Again, the "skb_" prefix is specific to the linux kernel, and
it is conceivable that other datapaths may easily implement the same
functionality by other means.
I'd be happy to send a patch accomplishing the above, if it is the right thing
to do. However, as I am not familiar with other datapaths, I may be completely
wrong in my assumptions regarding "skb" being specific to the Linux kernel
datapath. But i recall BSD using "mbufs" instead...
Jarno
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
