netdev - Re: Observed increased rate of non-linear UDP skb on 5.10 sfc driver

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]

Message-ID: <b2227f5d-5d87-57a6-d01a-4ee078617252@gmail.com>
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