On Wed, Apr 3, 2013 at 12:33 AM, Thomas Graf <tg...@suug.ch> wrote: > On 04/02/13 at 04:30pm, Jesse Gross wrote: >> Can you describe the race condition some more? The kernel doesn't >> change the port ID on its own so even needing to request the value >> seems rare. > > The upcall nlport is changeable with OVS_VPORT_CMD_SET and may > be received between the OVS_DP_CMD_GET and OVS_VPORT_CMD_GET. > >> Assigning the local ports upcall PID through datapath creation is >> really somewhat of a hack since it's port state. I don't disagree >> that it's somewhat asymmetric now but it seems better to move away >> from the current model if possible. > > Would you suggest to wait with local vport creation if no upcall > nlport is provided and let new user space binaries create the local > port explicitly? > > We can't get rid of the attribute in datapath messages w/o breaking > ABI but we could make its use optional I guess.
We have to keep the local port as part of datapath creation since it is used as an identifier for the datapath itself. However, you could probably achieve the same result by using a port ID of zero for the local port, which will prevent it from doing upcalls. You could then set it to a real value when you want to "create" it (this is actually what OVS userspace does). I think this is probably about as close to removing it as we can get. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
