On Thu, Mar 7, 2013 at 7:41 AM, Rajahalme, Jarno (NSN - FI/Espoo)
<jarno.rajaha...@nsn.com> wrote:
> 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.
To add to what Ansis said, it's likely that we'll want to use the mark
for a few different things beyond the current single bit indication of
IPsec, which is why the more general mechanism was introduced. Some
possibilities:
* More fine grained IPsec lookups, such as based on a certificate.
* As part of recirculation to connect multiple passes through the flow table.
* Other interactions with external Linux utilities like iptables.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
