netdev - Re: [PATCH net-next v1 1/2] net: core: count drops from GRO

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: <CANn89iK_yMC2LbA0N+=U3JACAGhciuLpQ_uCa3qZ1_fUbWCyUQ@mail.gmail.com>
Date:   Fri, 8 Jan 2021 23:17:06 +0100
From:   Eric Dumazet <edumazet@...gle.com>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Shannon Nelson <snelson@...sando.io>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        netdev <netdev@...r.kernel.org>,
        intel-wired-lan@...ts.osuosl.org,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH net-next v1 1/2] net: core: count drops from GRO

On Fri, Jan 8, 2021 at 9:27 PM Saeed Mahameed <saeed@...nel.org> wrote:
>

> I think there is still some merit in this patchset even with Eric's
> removal of GRO_DROP from gro_receive(). As Eric explained, it is still
> possible to silently drop for the same reason when drivers
> call napi_get_frags or even alloc_skb() apis, many drivers do not
> account for such packet drops, and maybe it is the right thing to do to
> inline the packet drop accounting into the skb alloc APIs ? the
> question is, is it the job of those APIs to update netdev->stats ?
>

You absolutely do not want to have a generic increment of
netdev->stats for multiqueue drivers.
This would add terrible cache line false sharing under DDOS and memory stress.

Each driver maintains (or should maintain) per rx queue counter for this case.

It seems  mlx4 does nothing special, I would suggest you fix it :)