netdev - Re: [PATCH mlx5-next 00/11] mlx5 core internal firmware events handling improvements

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] [day] [month] [year] [list]

Date:   Mon, 26 Nov 2018 22:16:27 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     Leon Romanovsky <leonro@...lanox.com>
CC:     Jason Gunthorpe <jgg@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: Re: [PATCH mlx5-next 00/11] mlx5 core internal firmware events
 handling improvements

On Tue, 2018-11-20 at 14:12 -0800, Saeed Mahameed wrote:
> Hi
> 
> This patchset is for mlx5-next shared branch, and will be applied
> there
> once the review is done.
> 
> The main idea of this change is to define a flexible scalable and
> simpler low level mlx5 core APIs to upper level components for better
> features decoupling and maximum code locality and modularity.
> 
> Improve and simplify mlx5 core internal firmware and device async
> events
> handling and subscription, currently all async firmware events are
> handled in one place (switch case in eq.c) and every time we need to
> update one of the mlx5_core handlers or add new events handling to
> the
> system, the driver needs to be changed in many places in order to
> deliver
> the new event to its consumer.
> 
> To improve this we will use atomic_notifier_chain to fire firmware
> events
> at internal mlx5 core components such as eswitch/fpga/clock/FW
> tracer/etc..,
> this is to avoid explicit calls from low level mlx5_core to upper
> components
> and to simplify the mlx5_core API for future developments.
>     
> Provide register/unregister notifiers API and call the notifier chain
> on
> firmware async events.
>     
> Example to subscribe to a FW event:
> 
> struct mlx5_nb port_event;
>     
> MLX5_NB_INIT(&port_event, port_event_handler, PORT_CHANGE);
> mlx5_eq_notifier_register(mdev, &port_event);
>     
> Where:
>   - port_event_handler is the notifier block callback.
>   - PORT_EVENT is the suffix of MLX5_EVENT_TYPE_PORT_CHANGE (The
> event
>     type to subscribe to)
> 
> The above will guarantee that port_event_handler will receive all FW
> events of the type MLX5_EVENT_TYPE_PORT_CHANGE.
>     
> To receive all FW/HW events one can subscribe to
> MLX5_EVENT_TYPE_NOTIFY_ANY.
>  
> There can be only 128 types of firmware events each has its own
> 64Byte 
> EQE (Event Queue Element) data, we will have one
> atomic_notifier_chain
> per event type for maximum performance and verbosity.
> Each handler is going to receive the event_type as unsigned long and
> the event data as void pointer, exactly as defined in the notifier
> block
> handlers prototype.
>    
> This API is implemented in the first patch of this series all
> following
> patches are modifying the existing mlx5 components to use the new API
> to
> subscribe to FW events.
> 
> Thanks,
> Saeed.
> 
> ---
> 
> Saeed Mahameed (11):
>   net/mlx5: EQ, Introduce atomic notifier chain subscription API
>   net/mlx5: FWTrace, Use async events chain
>   net/mlx5: FPGA, Use async events chain
>   net/mlx5: Clock, Use async events chain
>   net/mlx5: E-Switch, Use async events chain
>   net/mlx5: FWPage, Use async events chain
>   net/mlx5: CmdIF, Use async events chain
>   net/mlx5: Resource tables, Use async events chain
>   net/mlx5: CQ ERR, Use async events chain
>   net/mlx5: Device events, Use async events chain
>   net/mlx5: Improve core device events handling
> 


Applied to mlx5-next branch.

Thanks!