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().
Yes, we will be using first bit of skb mark (with help of masking) to
indicate that this packet is destined to IPsec tunnel. IPsec policies
will use skb_mark+remote_ip instead of protocol+remote_ip in
selectors. This is work in progress.
>
> 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.
Yes, skb_mark is limited to Linux. Other datapaths might have to
emulate it to get IPsec to work. There are few underlying reasons why
we have decided to go with skb mark approach in IPsec policies. To
name few:
1. linux datapath will not need to know anything about IPsec.
2. We will be able to use the same IPsec tunnel for GRE, VXLAN
3. We will be able to support simultaneously plain and ipsec tunnels
(e.g. gre and ipsec_gre)
>
> 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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
