>[...]
>> Unsigned variables are a little bit faster on ppc hardware. I figgured
>> that it doesn't matter on x86/x86_64, but would help other
architectures.
>
>Ok. No objection against an unsigned int or an u32 instead ?
I made them u32's, but in retrospect I should make them "unsigned int" for
code uniformity (i.e., the heavy usage of "unsigned long"). Actually, all
the driver u32's should be replaced with "unsigned int", and most of the
int's should probably be changed as well. I can make those changes if you
like, but that is outside the scope of this patch. :-)
[...]
>> I can try and hide as many #ifdefs as possible if you like, just didn't
>> know your preference. Will do.
>
>(sometimes hch is bored and dissects network patches too :o) )
>
>I have no suggestion for the others #ifdef but at least this one can be
>isolated.
I made this change. I will attempt to clean-up the #ifdefs more when I
have some free time.
[...]
>Anything as long as it avoids the indentation of a line in the
declaration
>block.
Removed the indentation.
[...]
>I fail to see where the Tx interrupts are disabled.
The code will now check for interrupts before it resets the interrupt mask
(and not reset it if an interrupt comes in). However, this won't really
be a problem if/when I add Tx to NAPI (which is why the error was there in
the first place).
[...]
>The locking scheme which will be used between ->poll() and ->interrupt()
>should guarantee some ordering of the registers operations (provided they
>appear in the locked section). However, if no read is issued, no one
knows
>when the write will actually hit the chipset.
I assume you are referring to the driver being used in weakly ordered
memory model machines. To address this I added a rmb() after the update
to the interrupt mask.
>> It might be better to be a user tunable parameter, but I can increase
the
>> size for NAPI usage. Any preference as to the ring size?
>
>256
Done.
>> Actually, I have a copy of the driver that does Tx. After reading the
>> NAPI howto, which states that there is a slight performance degradation
>> if Tx is NAPI too, I figgured that you would want only Rx. I can add
Tx
>> if you like.
>
>Separate patches are usually easier to review, yes.
I will add the Tx NAPI to the next version I send you.
Kconfig.diff
Description: Binary data
r8169.diff
Description: Binary data
|