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, 28 Nov 2022 11:54:50 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Alexander Lobakin <alexandr.lobakin@...el.com>
Cc:     Coco Li <lixiaoyan@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Michael Chan <michael.chan@...adcom.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] bnxt: Use generic HBH removal helper in tx
 path

On Wed, Nov 23, 2022 at 05:41:59PM +0100, Alexander Lobakin wrote:
> From: Coco Li <lixiaoyan@...gle.com>
> Date: Tue, 22 Nov 2022 15:27:40 -0800
> 
> > Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes
> > for IPv6 traffic. See patch series:
> > 'commit 89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")'
> > 
> > This reduces the number of packets traversing the networking stack and
> > should usually improves performance. However, it also inserts a
> > temporary Hop-by-hop IPv6 extension header.
> > 
> > Using the HBH header removal method in the previous path, the extra header
> > be removed in bnxt drivers to allow it to send big TCP packets (bigger
> > TSO packets) as well.
> > 
> > If bnxt folks could help with testing this patch on the driver (as I
> > don't have access to one) that would be wonderful. Thank you!
> > 
> > Tested:
> > Compiled locally
> 
> Please mark "potential" patches with 'RFC'. Then, if/when you get a
> 'Tested-by:', you can spin a "true" v1.

We are getting ton of patches which are "compiled-only".
I won't be such strict with them as long as they stated clearly about it.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ