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:   Thu, 21 Jan 2021 16:32:37 +0000
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Mark Pashmfouroush <mpashmfouroush@...udflare.com>,
        netdev@...r.kernel.org
Cc:     habetsm.xilinx@...il.com, lmb@...udflare.com
Subject: Re: Observed increased rate of non-linear UDP skb on 5.10 sfc driver

On 21/01/2021 13:04, Mark Pashmfouroush wrote:
> My question is, what can cause a fragmented/non-linear UDP skb to be> allocated by the sfc driver, and why has this frequency increased since
> transitioning to the in-tree driver?
By default sfc doesn't RX things as linear; we get one or more RX buffers
 from the hardware and then we attach them as frags to an skb; see
 efx_rx_mk_skb().  We then pull 'hdr_len' bytes from the first frag into
 the linear area; if the total packet length happens to be <= hdr_len then
 the resulting skb will be linear.
hdr_len comes from the caller, efx_rx_deliver().  In-tree we pass
 EFX_SKB_HEADERS, #defined as 128; out-of-tree it's a module parameter
 'rx_copybreak' (internally rx_cb_size) which defaults to 192.  That's
 probably what's causing your difference: some of your packets are between
 128 and 192 bytes in length.
You could verify this theory by seeing what happens if you set rx_copybreak
 to 128 on the out-of-tree driver; you should get the same behaviour as
 with in-tree.

-ed

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ