if_var.h micro-optimization

[Bruce M. Simpson]

rihad wrote:
> Bruce M. Simpson wrote:
>>
>> It could save dirtying an L2 data cache line at the expense of taking 
>> a conditional branch,
> Whoa, why don't you take it easy on me :) I'm not that much into 
> kernel (or hardware) programming. It's just that reading Ch. 3 of 
> TCP/IP Illustrated Vol.2 by Rich Stevens got me digging around FreeBSD 
> source code dealing with struct ifnet, where this piece of code caught 
> my attention.

It could be red, it could be yellow. It could be 620nm. Who am I to say 
what is and what isn't? ;-)

There are bound to be situations where the change is a win, and even 
some where there isn't. Context is everything...

>> but to evaluate your suggested change requires a lot more data. Do 
>> you plan to do this? 
> Perhaps there is already a framework for trying out changes in 
> -CURRENT and seeing their relative impact, so perhaps someone more 
> experienced than I am can see to this?

All educators are busy right now, please hold and the next available 
dogma merchant will be with you as soon as possible. ;-)

(Hint: No, there isn't a framework I know of, unless you wanna make one? 
Scientific process applies, reproducible results, etc. You could script 
stuff, figure out a way to run the kernel or parts of the network stack 
under Valgrind so it can be L2 profiled w/o running it on a real 
machine... or hack hwpmc so it can be done live.. anything is possible.)

>
>> Given how _IF_DEQUEUE() is normally used the impact is likely 
>> negligible.
> Oh, I see. A nice first attempt of mine anyway ;) Thanks.

Don't take my word for it, down that road lies darkness.

Seriously though -- it's easy to introduce bugs doing things like this, 
if anything else it's an exercise in really thinking things through.

cheers
BMS