[ovs-dev] [netlink v4 49/52] datapath: Convert ODP_DP_* commands to use AF_NETLINK socket layer.

Jesse Gross jesse at nicira.com
Mon Jan 24 22:25:54 UTC 2011


On Mon, Jan 24, 2011 at 1:53 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Sun, Jan 23, 2011 at 03:55:14PM -0800, Jesse Gross wrote:
>> In this case, though since the reply is unicast we can just directly
>> return an error code, which is what we are already doing.  So we're
>> fine for now but will need this when we do multicast.  Should we do it
>> for upcalls, the one place where we currently do multicast?
>
> Yes, I think that we should.  The fix for this (incremental appended)
> required some intrusive new compat code.  Do you see a better way to do
> it?

No, I don't have anything better.  What you have below looks good.

>> >> It's also not really clear to me when we should send a reply. ?We have:
>> >> * New objects unicast a response back.
>> >> * Flows unicast a response on deletion.
>> >> * Ports multicast notifications on creation and deletion as the bridge
>> >> does through RTNL.
>> >
>> > Yes, this needs to be made consistent. ?I believe that the "correct" way
>> > to do it is that each type of object should multicast its status on
>> > creation, deletion, or change. ?(I think that the goal is supposed to be
>> > to allow userspace to accurately track the changes in a table over time;
>> > that's essentially what libnl allows one to do.) ?This is on my to-do
>> > list, along with using sk_buff frags for long sets of flow actions. ?It
>> > shouldn't be too difficult; I was just tired when I wrote this code.
>>
>> OK, that makes sense to me.  Should we also keep the existing RTNL
>> notifications?  It feels like compatibility code.
>
> These are needed for brcompat.

OK, but it's not something you think we actually want on it's own
merit and would remove it before upstreaming?




More information about the dev mailing list