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  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, 02 Jul 2007 10:25:49 -0400
From:	Jeff Garzik <>
To:	Arjan van de Ven <>
CC:	Ayyappan Veeraiyan <>,,,
Subject: Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based
 PCI	Express adapters...

Arjan van de Ven wrote:
>  >> +    u32 alloc_rx_buff_failed;
>>> +    struct {
>>> +        unsigned int rx_csum_enabled    :1;
>>> +        unsigned int msi_capable    :1;
>>> +        unsigned int msi_enabled    :1;
>>> +        unsigned int msix_capable    :1;
>>> +        unsigned int msix_enabled    :1;
>>> +        unsigned int imir_enabled    :1;
>>> +        unsigned int in_netpoll        :1;
>>> +    } flags;
>> always avoid bitfields.  They generate horrible code, and endian 
>> problems abound (though no endian problems are apparent here).
> they generate no worse code than open coding the checks for these 
> feature flags...

That would be the logical assumption, but reality does not bear that 
logic out to be true.

I'm not sure whether gcc is confused about ABI alignment or such, on 
various platforms, but every time I look at the asm generated it is 
/not/ equivalent to open-coded feature flags and bitwise logic.  Often 
it is demonstrably worse.

The same is true for icc too :)  Bitfields are just bad juju for 
compilers, I guess.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists