if_var.h micro-optimization
Not sure if this is a worthwhile optimization? FreeBSD 7.0
--- /usr/src/sys/net/if_var.h 2007-12-07 09:46:08.0 +0400
+++ if_var.h2008-05-30 18:10:25.0 +0500
@@ -282,7 +282,8 @@
if (m) {\
if (((ifq)-ifq_head = (m)-m_nextpkt) == NULL) \
(ifq)-ifq_tail = NULL; \
- (m)-m_nextpkt = NULL; \
+ else\
+ (m)-m_nextpkt = NULL; \
(ifq)-ifq_len--; \
} \
} while (0)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_var.h micro-optimization
rihad wrote:
Not sure if this is a worthwhile optimization? FreeBSD 7.0
--- /usr/src/sys/net/if_var.h 2007-12-07 09:46:08.0 +0400
+++ if_var.h2008-05-30 18:10:25.0 +0500
@@ -282,7 +282,8 @@
if (m) {\
if (((ifq)-ifq_head = (m)-m_nextpkt) == NULL) \
(ifq)-ifq_tail = NULL; \
- (m)-m_nextpkt = NULL; \
+ else\
+ (m)-m_nextpkt = NULL; \
(ifq)-ifq_len--; \
} \
} while (0)
It could save dirtying an L2 data cache line at the expense of taking a
conditional branch, but to evaluate your suggested change requires a lot
more data. Do you plan to do this? Given how _IF_DEQUEUE() is normally
used the impact is likely negligible.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_var.h micro-optimization
Bruce M. Simpson wrote:
rihad wrote:
Not sure if this is a worthwhile optimization? FreeBSD 7.0
--- /usr/src/sys/net/if_var.h 2007-12-07 09:46:08.0 +0400
+++ if_var.h2008-05-30 18:10:25.0 +0500
@@ -282,7 +282,8 @@
if (m) {\
if (((ifq)-ifq_head = (m)-m_nextpkt) == NULL) \
(ifq)-ifq_tail = NULL; \
- (m)-m_nextpkt = NULL; \
+ else\
+ (m)-m_nextpkt = NULL; \
(ifq)-ifq_len--; \
} \
} while (0)
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.
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?
Given how _IF_DEQUEUE() is normally
used the impact is likely negligible.
Oh, I see. A nice first attempt of mine anyway ;) Thanks.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_var.h micro-optimization
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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
