netdev - Re: [net-next 06/13] bna: UDP RX Processing Improvements

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:	Tue, 10 Dec 2013 21:11:20 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	rmody@...cade.com
Cc:	netdev@...r.kernel.org, adapter_linux_open_src_team@...cade.COM
Subject: Re: [net-next 06/13] bna: UDP RX Processing Improvements

From: Rasesh Mody <rmody@...cade.com>
Date: Tue, 10 Dec 2013 16:05:46 -0800

> By having the bnad_rx_unmap structure marked as __packed we were trying to
> reduce the unmap_q size by 16K, __packed would ensure the RX unmap
> structure of 40 bytes is packed to 32 bytes. This change was also captured
> as a part of the commit message of patch #6 under change details.

Do you have any idea what the costs are on certain architectures
for adding this attribute?

When you mark something __packed, the compiler can no longer assume
anything about the alignment of any instance of that structure, nor
nor any structure which is contained within that type either.

So the compiler will, for example, emit byte by byte operations
to load multi-byte quantities on architectures where unaligned
data accesses can trap.

You should only use __packed as the extreme, very last resort method
to achieve a certain goal.  Frankly I think it should never be used
except in cases where layout is dictated by a network protocol or
hardware descriptor _AND_ the layout cannot be achieved using portable
fixed sized types.

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