Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: hhPTvVM0iAl3d0+AfH3apqIocAbWVfEt9mADUmRBK8hytTT2Gosvsz5ZS17y0OL5MRRjEpOFbv
 MJNLy/RSiVVpKVTscaufeEBV9KbTorOXZj2Gz7eCvm5fmXwdnIsX7F0aGlJ6lRGPZXwWQ+oHeO
 4huPh1kxohxnOIBiZuE+BCdme2ssaBMV4OO9tLT/aFIinggVl5YWZRvfair+EkqKiM758/YCU8
 7K+G4CSW0DkT+TJWCWOQGkAiIM1c3f7dyVkXqEZp0tWeR1bgGrZxRV1fMjgqpsPQAE9z0Wg4P4
 htQ=
Date:   Mon, 5 Oct 2020 15:07:12 +0200
From:   "Allan W. Nielsen" <allan.nielsen@microchip.com>
To:     Jiri Pirko <jiri@resnulli.us>
CC:     Henrik Bjoernlund <henrik.bjoernlund@microchip.com>,
        <davem@davemloft.net>, <kuba@kernel.org>, <roopa@nvidia.com>,
        <nikolay@nvidia.com>, <jiri@mellanox.com>, <idosch@mellanox.com>,
        <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
        <bridge@lists.linux-foundation.org>,
        <UNGLinuxDriver@microchip.com>,
        "Horatiu Vultur" <horatiu.vultur@microchip.com>
Subject: Re: [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface
 implementation
Message-ID: <20201005130712.ybbgiddb7bnbkz6h@ws.localdomain>
References: <20201001103019.1342470-1-henrik.bjoernlund@microchip.com>
 <20201001103019.1342470-11-henrik.bjoernlund@microchip.com>
 <20201001124929.GM8264@nanopsycho>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Disposition: inline
In-Reply-To: <20201001124929.GM8264@nanopsycho>
Precedence: bulk

Hi Jiri

On 01.10.2020 14:49, Jiri Pirko wrote:
>EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>Thu, Oct 01, 2020 at 12:30:18PM CEST, henrik.bjoernlund@microchip.com wrote:
>>This is the definition of the CFM switchdev interface.
>>
>>The interface consist of these objects:
>>    SWITCHDEV_OBJ_ID_MEP_CFM,
>>    SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM,
>>    SWITCHDEV_OBJ_ID_CC_CONFIG_CFM,
>>    SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM,
>>    SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM,
>>    SWITCHDEV_OBJ_ID_MEP_STATUS_CFM,
>>    SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM
>>
>>MEP instance add/del
>>    switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CFM)
>>    switchdev_port_obj_del(SWITCHDEV_OBJ_ID_MEP_CFM)
>>
>>MEP cofigure
>>    switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM)
>>
>>MEP CC cofigure
>>    switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CONFIG_CFM)
>>
>>Peer MEP add/del
>>    switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM)
>>    switchdev_port_obj_del(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM)
>>
>>Start/stop CCM transmission
>>    switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM)
>>
>>Get MEP status
>>       switchdev_port_obj_get(SWITCHDEV_OBJ_ID_MEP_STATUS_CFM)
>>
>>Get Peer MEP status
>>       switchdev_port_obj_get(SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM)
>>
>>Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
>>Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
>
>You have to submit the driver parts as a part of this patchset.
>Otherwise it is no good.
Fair enough.

With MRP we did it like this, and after Nik asked for details on what is
being offload, we thought that adding this would help.

The reason why we did not include the implementation of this interface
is that it is for a new SoC which is still not fully available which is
why we have not done the basic SwitchDev driver for it yet. But the
basic functionality clearly needs to come first.

Our preference is to continue fixing the comments we got on the pure SW
implementation and then get back to the SwitchDev offloading.

This will mean dropping the last 2 patches in the serie.

Does that work for you Jiri, and Nik?

/Allan