On Feb 3, 2014, at 9:56 AM, Jesse Gross <je...@nicira.com> wrote: > On Fri, Jan 24, 2014 at 2:58 PM, Jarno Rajahalme <jrajaha...@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 <jrajaha...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
