[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEP_g=8MtthzO=P-JpTE0jH23_EaU+rp4qiwv_Y721vxyZuFTw@mail.gmail.com>
Date: Tue, 17 Dec 2013 09:49:00 -0800
From: Jesse Gross <jesse@...ira.com>
To: Thomas Graf <tgraf@...hat.com>
Cc: "dev@...nvswitch.org" <dev@...nvswitch.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] linux: Signal datapath that unaligned Netlink message
can be received
On Tue, Dec 17, 2013 at 1:52 AM, Thomas Graf <tgraf@...hat.com> wrote:
> On 12/17/2013 02:23 AM, Jesse Gross wrote:
>>
>> On Sat, Nov 30, 2013 at 4:25 AM, Thomas Graf <tgraf@...hat.com> wrote:
>>>
>>> diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
>>> index 6c482d0..2d8a1aa 100644
>>> --- a/lib/dpif-linux.c
>>> +++ b/lib/dpif-linux.c
>>> @@ -73,6 +73,7 @@ struct dpif_linux_dp {
>>> /* Attributes. */
>>> const char *name; /* OVS_DP_ATTR_NAME. */
>>> const uint32_t *upcall_pid; /* OVS_DP_ATTR_UPCALL_PID. */
>>> + uint32_t user_features; /* OVS_DP_ATTR_USER_FEATURES */
>>> struct ovs_dp_stats stats; /* OVS_DP_ATTR_STATS. */
>>> struct ovs_dp_megaflow_stats megaflow_stats;
>>> /* OVS_DP_ATTR_MEGAFLOW_STATS.*/
>>> @@ -228,6 +229,7 @@ dpif_linux_open(const struct dpif_class *class
>>> OVS_UNUSED, const char *name,
>>> dp_request.cmd = OVS_DP_CMD_NEW;
>>> upcall_pid = 0;
>>> dp_request.upcall_pid = &upcall_pid;
>>> + dp_request.user_features |= OVS_DP_F_UNALIGNED;
>>> } else {
>>> dp_request.cmd = OVS_DP_CMD_GET;
>>> }
>>
>>
>> Does this handle the case where we are opening an existing datapath
>> and need to update the features?
>
>
> The patch (''openvswitch: Drop user features if old user space attempted
> to create datapath'') takes care of resetting the features for the
> downgrade case. The upgrade case with a persistent datapath object is
> currently not implemented. The datapath object needs to be recreated.
I think there's also a potential downgrade issue if we add a new
feature to the list of capabilities - it won't automatically reset
since userspace is now using v2 of the netlink protocol. Obviously,
this isn't an issue yet but it we should make sure that it is
addressed before there is a release.
> Defining the NLM_F_REPLACE semantics is non trivial if we want to do
> more than just update the settings. I will propose this in a follow up
> patch.
Couldn't userspace just issue an OVS_DP_CMD_SET on start?
--
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