[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEP_g=-Q=MtTWTC0sO1B27ZBszHm3Tv5Bc5gRCt2JEZrA5vM9g@mail.gmail.com>
Date: Wed, 3 Apr 2013 13:17:28 -0700
From: Jesse Gross <jesse@...ira.com>
To: Thomas Graf <tgraf@...g.ch>
Cc: "dev@...nvswitch.org" <dev@...nvswitch.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] openvswitch: Provide OVS_DP_ATTR_UPCALL_PID in
datapath messages
On Wed, Apr 3, 2013 at 12:33 AM, Thomas Graf <tgraf@...g.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists