netdev - Re: [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Oct 2020 15:07:12 +0200
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     Henrik Bjoernlund <henrik.bjoernlund@...rochip.com>,
        <davem@...emloft.net>, <kuba@...nel.org>, <roopa@...dia.com>,
        <nikolay@...dia.com>, <jiri@...lanox.com>, <idosch@...lanox.com>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <bridge@...ts.linux-foundation.org>,
        <UNGLinuxDriver@...rochip.com>,
        "Horatiu Vultur" <horatiu.vultur@...rochip.com>
Subject: Re: [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface
 implementation

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@...rochip.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@...rochip.com>
>>Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@...rochip.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