d80211: remove bitfields from include/net/d80211.h
Subsystems (2)
cover d80211: remove bitfields from include/net/d80211.h
Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from include/net/d80211.h.
I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent.
This should be a no-op from a functionality standpoint.
All tests using gcc 4.1.2.
The size of structures where bitfields were removed is identical patched and unpatched. All object text size is either slightly smaller after the patch, or unchanged (bss and data are all unchanged). With all d80211 drivers compiled in the patched vmlinux is 1232 bytes smaller.
Changes from take2:
Refresh to apply to current wireless-dev.
Changes from take1:
Update rt2500usb.c and rt73usb.c drivers based on the new structures.
Changes from take0:
Update the patches to apply on top of the following patches:
d80211: remove unused Super AG definitions, purge comment
(http://marc.theaimsgroup.com/?l=linux-netdev&m=116102409931269&w=2) d80211: remove initialization of unused xr structure members (http://marc.theaimsgroup.com/?l=linux-netdev&m=116076811809305&w=4) d80211: remove unused xr structure members, interface, etc. (http://marc.theaimsgroup.com/?l=linux-netdev&m=115989929600617&w=4)
For key_conf_bitfields.patch change the new flags member to u8 from u32.
For tx_control_bitfields.patch move the rts_cts_duration and retry_limit members in ieee80211_tx_control to allow for smaller structure size and change the flags member from u32 to u16.
For tx_status_bitfields.patch, in drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c and drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c note that ieee80211_tx_status is already zero'd, so the ack bit only needs to be set, not cleared.
--
Quoted 7 lines · David Kimdon
Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from
include/net/d80211.h.I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent.
For bit flags, usually it is best to use up to 32 bits of an unsigned long, which guarantees that you use a machine integer for all platforms.
Jeff
Quoted 5 lines · Jeff Garzik
Quoted 4 lines · David Kimdon
Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from
include/net/d80211.h.
Quoted 7 lines
Quoted 3 lines
I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent.
For bit flags, usually it is best to use up to 32 bits of an unsigned long, which guarantees that you use a machine integer for all platforms.
That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal.
For the key_conf bitfields size doesn't matter much. For the tx_control bitfields size matters a bit more since it is needed per-packets and dirvers currently need to store a copy to pass to the tx complete handler.
Thoughts?
David
Quoted 3 lines · David Kimdon
That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal.
On non-x86 platforms, u16 and u8 generate shitty code too. Not as shitty as bitfields, but still shitty.
Jeff
Quoted 7 lines · Jeff Garzik
Quoted 3 lines · David Kimdon
That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal.
On non-x86 platforms, u16 and u8 generate shitty code too. Not as shitty as bitfields, but still shitty.
David, may I presume there will be a "take4"?
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 1 line · John W. Linville
David, may I presume there will be a "take4"?
yes, refreshing is in progress.