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  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]
Date:   Mon, 19 Oct 2020 08:33:27 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Florian Fainelli' <>,
        Vladimir Oltean <>,
        "" <>
CC:     "" <>,
        "" <>,
        "" <>,
        "Christian Eggers" <>,
        Kurt Kanzenbach <>
Subject: RE: [RFC PATCH 02/13] net: dsa: implement a central TX reallocation

From: Florian Fainelli>
> Sent: 17 October 2020 23:12
> Not positive you need that because you may be account for more head or
> tail room than necessary.
> For instance with tag_brcm.c and systemport.c we need 4 bytes of head
> room for the Broadcom tag and an additional 8 bytes for pushing the
> transmit status block descriptor in front of the Ethernet frame about to
> be transmitted. These additional 8 bytes are a requirement of the DSA
> master here and exist regardless of DSA being used, but we should not be
> propagating them to the DSA slave.

Is it possible to send the extra bytes from a separate buffer fragment?
The entire area could be allocated (coherent) when the rings are
That would save having to modify the skb at all.

Even if some bytes of the frame header need 'adjusting' transmitting
from a copy may be faster - especially on systems with an iommu.

Many (many) moons ago we found the cutoff point for copying frames
on a system with an iommu to be around 1k bytes.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists