netdev - Re: [PATCH net-next 0/6 v3] qed*: Doorbell overflow recovery

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:   Fri, 30 Nov 2018 13:45:29 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     Ariel.Elior@...ium.com
Cc:     netdev@...r.kernel.org, Michal.Kalderon@...ium.com,
        Tomer.Tayar@...ium.com
Subject: Re: [PATCH net-next 0/6 v3] qed*: Doorbell overflow recovery

From: Ariel Elior <Ariel.Elior@...ium.com>
Date: Wed, 28 Nov 2018 18:16:01 +0200

> Doorbell Overflow
> If sufficient CPU cores will send doorbells at a sufficiently high rate, they
> can cause an overflow in the doorbell queue block message fifo. When fill level
> reaches maximum, the device stops accepting all doorbells from that PF until a
> recovery procedure has taken place.
> 
> Doorbell Overflow Recovery
> The recovery procedure basically means resending the last doorbell for every
> doorbelling entity. A doorbelling entity is anything which may send doorbells:
> L2 tx ring, rdma sq/rq/cq, light l2, vf l2 tx ring, spq, etc. This relies on
> the design assumption that all doorbells are aggregative, so last doorbell
> carries the information of all previous doorbells.
> 
> APIs
> All doorbelling entities need to register with the mechanism before sending
> doorbells. The registration entails providing the doorbell address the entity
> would be using, and a virtual address where last doorbell data can be found.
> Typically fastpath structures already have this construct.
> 
> Executing the recovery procedure
> Handling the attentions, iterating over all the registered entities and
> resending their doorbells, is all handled within qed core module.
> 
> Relevance
> All doorbelling entities in all protocols need to register with the mechanism,
> via the new APIs. Technically this is quite simple (just call the API). Some
> protocol fastpath implementation may not have the doorbell data stored anywhere
> (compute it from scratch every time) and will have to add such a place.
> This is rare and is also better practice (save some cycles on the fastpath).
> 
> Performance Penalty
> No performance penalty should incur as a result of this feature. If anything
> performance can improve by avoiding recalcualtion of doorbell data everytime
> doorbell is sent (in some flows).
> 
> Add the database used to register doorbelling entities, and APIs for adding
> and deleting entries, and logic for traversing the database and doorbelling
> once on behalf of all entities.
> 
> Please consider applying to net-next.

Series applied, thanks.