[ovs-dev] Any other planned use for userspace skb_mark?

Jesse Gross jesse at nicira.com
Thu Mar 7 19:30:38 UTC 2013


On Thu, Mar 7, 2013 at 7:41 AM, Rajahalme, Jarno (NSN - FI/Espoo)
<jarno.rajahalme at 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.



More information about the dev mailing list