netdev - Re: [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel

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: <542D37FA.3050708@oracle.com>
Date:	Thu, 02 Oct 2014 07:33:14 -0400
From:	David L Stevens <david.stevens@...cle.com>
To:	David Laight <David.Laight@...LAB.COM>,
	"'Raghuram Kothakota'" <Raghuram.Kothakota@...cle.com>
CC:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy
 in the kernel



On 10/02/2014 05:06 AM, David Laight wrote:

>>> 	len = skb->len;
>>> -	if (len < ETH_ZLEN) {
>>> +	if (len < ETH_ZLEN)
>>> 		len = ETH_ZLEN;
>>> -		memset(tx_buf+VNET_PACKET_SKIP+skb->len, 0, len - skb->len);
>>> +
> 
> Aren't you transmitting 'random' bytes from the end of the data?
> Plausibly they might not even be mapped.

	No. The checks to decide whether to copy or not make sure the
extra 6-14 bytes in the beginning and 0-8 bytes (for large frames, more
for small) at the end are part of the particular skb's headroom and
tailroom respectively. So, they aren't random bytes-- they are what
was allocated as part of the frame. For TCP streams, the trailing bytes
are likely part of the next packet. They definitely exist and are mapped,
but I don't zero them because they are usually COW and that forces a copy
every time.

> 
> Also, for short frames the copy could well be faster - especially on systems
> with non-trivial iommu.
> It is also worth checking whether the original copy was aligned.

For the short frames, sure. I'm not sure what you mean by that last sentence--
the point of the checks that determine whether to copy or not are to enforce
alignment and length restrictions; if they aren't met in the original buffer,
we copy.

						+-DLS
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html