[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