[ovs-dev] [RFC PATCH 1/4] datapath: Reply with minimal netlink attributes (if requested).

[Jarno Rajahalme]

On Feb 3, 2014, at 9:56 AM, Jesse Gross <jesse at nicira.com> wrote:

> On Fri, Jan 24, 2014 at 2:58 PM, Jarno Rajahalme <jrajahalme at nicira.com> wrote:
>> Userspace already sets NLM_F_ECHO when it wants a reply, make use of
>> it.
>> 
>> For set and del, OVS userspace only sets the NLM_F_ECHO if stats are
>> needed back.  So, we minimize the data sent back by only responding
>> with key and stats for ovs_flow_cmd_new, ovs_flow_cmd_set, and
>> ovs_flow_cmd_del.
>> 
>> When not returning actions, we can allocate the reply (if requested)
>> before finding the flow, i.e., before locking anything.  We make use
>> of this in following patches.
>> 
>> Signed-off-by: Jarno Rajahalme <jrajahalme at nicira.com>
> 
> I think this is too tailored to what userspace is currently expecting
> today. Currently, we send notifications of flow changes to a multicast
> group and any other subscribers should get notifications even if
> NLM_F_ECHO is not set. In addition, dropping certain fields depending
> on what we currently need is definitely API breakage and seems error
> prone in the future.
> 

Thanks, I wasn’t sure of any current use of the NLM_F_ECHO feature outside
of the OVS userspace (or in past OVS versions), and hence marked the series
as RFC.

Is there a way to find out if there are any other subscribers around? I still think
it would be better not allocate and fill the response if we could know no-one is
interested in it.

> If the primary benefit here is not holding a lock while doing memory
> allocation then it seems like we could still make a change along these
> lines by doing optimistic allocation where we do a lookup with a read
> lock, allocate the response, and then take the write lock to check the
> result and perform the action.


I’ll try this out, so we’ll see.

  Jarno