netdev - RE: [RFC PATCH 02/13] net: dsa: implement a central TX reallocation procedure

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: <049e7fd8f46c43819a05689fe464df25@AcuMS.aculab.com>
Date:   Mon, 19 Oct 2020 08:33:27 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Florian Fainelli' <f.fainelli@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "andrew@...n.ch" <andrew@...n.ch>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "Christian Eggers" <ceggers@...i.de>,
        Kurt Kanzenbach <kurt@...utronix.de>
Subject: RE: [RFC PATCH 02/13] net: dsa: implement a central TX reallocation
 procedure

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
allocated.
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.

	David

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