netdev - Re: [PATCH net-next V3 4/8] devlink: Expose port function commands to control RoCE

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]

Message-ID: <34381666-a7b5-9507-211a-162827b86153@amd.com>
Date:   Mon, 5 Dec 2022 15:37:26 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Shay Drory <shayd@...dia.com>, netdev@...r.kernel.org,
        kuba@...nel.org, davem@...emloft.net
Cc:     danielj@...dia.com, yishaih@...dia.com, jiri@...dia.com,
        saeedm@...dia.com, parav@...dia.com
Subject: Re: [PATCH net-next V3 4/8] devlink: Expose port function commands to
 control RoCE

On 12/4/22 6:16 AM, Shay Drory wrote:
> Expose port function commands to enable / disable RoCE, this is used to
> control the port RoCE device capabilities.
> 
> When RoCE is disabled for a function of the port, function cannot create
> any RoCE specific resources (e.g GID table).
> It also saves system memory utilization. For example disabling RoCE enable a
> VF/SF saves 1 Mbytes of system memory per function.
> 
> Example of a PCI VF port which supports function configuration:
> Set RoCE of the VF's port function.
> 
> $ devlink port show pci/0000:06:00.0/2
> pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0
> vfnum 1
>      function:
>          hw_addr 00:00:00:00:00:00 roce enable
> 
> $ devlink port function set pci/0000:06:00.0/2 roce disable
> 
> $ devlink port show pci/0000:06:00.0/2
> pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0
> vfnum 1
>      function:
>          hw_addr 00:00:00:00:00:00 roce disable
> 
> Signed-off-by: Shay Drory <shayd@...dia.com>
> Reviewed-by: Jiri Pirko <jiri@...dia.com>
> ---



> +
> +#define DEVLINK_PORT_FN_CAP_ROCE _BITUL(DEVLINK_PORT_FN_ATTR_CAP_ROCE_BIT)
> +
>   enum devlink_port_function_attr {
>          DEVLINK_PORT_FUNCTION_ATTR_UNSPEC,
>          DEVLINK_PORT_FUNCTION_ATTR_HW_ADDR,     /* binary */
>          DEVLINK_PORT_FN_ATTR_STATE,     /* u8 */
>          DEVLINK_PORT_FN_ATTR_OPSTATE,   /* u8 */
> +       DEVLINK_PORT_FN_ATTR_CAPS,      /* bitfield32 */

Will 32 bits be enough, or should we start off with u64?  It will 
probably be fine, but since we're setting a uapi thing here we probably 
want to be sure we won't need to change it in the future.

sln