[ovs-dev] [PATCH] v2 datapath: More flexible kernel/userspace tunneling attribute.

Jesse Gross jesse at nicira.com
Thu Jan 17 21:02:46 UTC 2013


On Thu, Jan 17, 2013 at 12:51 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Wed, Jan 16, 2013 at 6:41 PM, Jesse Gross <jesse at nicira.com> wrote:
>> On Wed, Jan 16, 2013 at 1:54 PM, Pravin B Shelar <pshelar at nicira.com> wrote:
>>> diff --git a/datapath/datapath.c b/datapath/datapath.c
>>> index ed69af8..4ed40e2 100644
>>> --- a/datapath/datapath.c
>>> +++ b/datapath/datapath.c
>>> +static struct nlattr *reserve_sfa_size(struct sw_flow_actions **sfa, int attr_len)
>>> +{
>>> +
>>> +       struct sw_flow_actions *new;
>>> +       struct nlattr *a;
>>> +
>>> +       if (NLA_ALIGN(attr_len) <= (ksize(*sfa) - (*sfa)->actions_len))
>>> +               goto out;
>>> +
>>> +       if (ksize(*sfa) * 2 > MAX_ACTIONS_BUFSIZE)
>>> +               return ERR_PTR(-EMSGSIZE);
>>
>> It's possible that the current size is smaller than
>> MAX_ACTIONS_BUFSIZE but 2 * size is larger.  This probably is not
>> likely because kmalloc will round up to a power of two and
>> MAX_ACTIONS_BUFSIZE is a power of two but I'm not sure that we want to
>> implicitly assume that.
>>
> right , so max allocation will of size MAX_ACTIONS_BUFSIZE. should we
> increment size more slowly?

I don't mean to increment more slowly but to make sure that we
actually hit MAX_ACTIONS_BUFSIZE.  If the initial allocation and
MAX_ACTIONS_BUFSIZE are powers of two and we increment by a factor of
two then this is guaranteed.  However, if it's not then we could end
up in a situation where the current buffer is 10k and the max is 16k
so we wouldn't increase the size because that would put us over the
limit.  I would either allow us to go to 16k in this case or ensure
that the safe conditions are always true.



More information about the dev mailing list