[ovs-dev] [netlink v4+3] datapath: Append ODFPT_ACTIONS attribute as fragments.

[Jesse Gross]

On Mon, Jan 24, 2011 at 12:03 PM, Ben Pfaff <blp at nicira.com> wrote:
> Here's a simpler version that works differently but does work.

Yeah, Netlink seems to have a lot of assumptions about the skb being
linear so this seems the safest.

> diff --git a/datapath/datapath.c b/datapath/datapath.c
> index c2b07f6..80d9745 100644
> --- a/datapath/datapath.c
> +++ b/datapath/datapath.c
> +       /* Put ODP_FLOW_ATTR_ACTIONS, expanding the skb if necessary.  This is
> +        * unusual for Netlink but individual action lists can be longer than a
> +        * page and thus entirely undumpable if we didn't do this. */
> +       nla_len = nla_total_size(sf_acts->actions_len);
> +       if (nla_len > skb_tailroom(skb)) {
> +               int hdr_off = (unsigned char *)odp_flow - skb->data;
> +
> +               err = pskb_expand_head(skb, 0, nla_len - skb_tailroom(skb), GFP_KERNEL);
> +               if (err)
> +                       goto error;
> +
> +               odp_flow = (struct odp_flow *)(skb->data + hdr_off);
> +       }
> +       nla = nla_nest_start(skb, ODP_FLOW_ATTR_ACTIONS);
> +       memcpy(__skb_put(skb, sf_acts->actions_len), sf_acts->actions, sf_acts->actions_len);
> +       nla_nest_end(skb, nla);

This will trigger skb expansion even in fairly common cases without
huge action lists.  If we are in the middle of a dump and it's the
action list that causes us to trip over the limit then we'll expand
the current skb instead of waiting for the next one.  I think ideally
we would expand only if the total size of the flow cannot be contained
in a single skb.