[RFC][RFT] overhaul if_gre(4)
Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 Split if_gre(4) into two modules, if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * make implementation conform to the RFC 2784 and partially to RFC 2890; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove caching routes support. This fixes problem, when gre(4) doesn't work at system startup. But this also removes ability to have tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, use our standard ioctls for tunnels. me(4): * use the same locking model as gre(4); * use if_transmit; * implementation conform to RFC 2004; -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [RFC][RFT] overhaul if_gre(4)
On 29.10.2014 12:35, Andrey V. Elsukov wrote: Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 For those who want to test, I prepared a tarball with sources https://people.freebsd.org/~ae/gre.tgz Modules should work on stable/10 and head/ without modifications. And they will not work on stable/9. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Intel DPDK added to FreeBSD ports collection
Hi, On 2014-10-20, at 17:40, Jim Harris jimhar...@freebsd.org wrote: Just wanted to send a heads-up that Intel's Data Plane Development Kit (DPDK) for high speed packet processing was added to the FreeBSD ports collection last week under net/dpdk. ... For any questions, please check out dpdk.org and the developer mailing list (d...@dpdk.org). that list seems to be more about the development of the kit, rather that about using the kit? I've started to play with DPDK under FreeBSD, and am getting the following warning: EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is not available - clock timings may be less accurate. This is with the HPET changes rpaulo@ recently committed, and /dev/hpet0 is present. Lars smime.p7s Description: S/MIME cryptographic signature
RE: ipfw fwd duplicating packets in 9.3-RELEASE
Hi, I cannot help to point out when the ICMP packet was duplicated and transfer via 2 different links, If it happens in my machine, I will call this feature multi-homing. But what I want to say is the firewall rule fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 You can remove the out because xmit will check the out interface. Regards, Bycn82 -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Raimundo Santos Sent: Tuesday, 28 October, 2014 3:32 PM To: freebsd-net@freebsd.org Subject: ipfw fwd duplicating packets in 9.3-RELEASE Hello list! I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, latest updates, GENERIC kernel, in this setup: 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as network machines, each one connected to FreeBSD via one port. It is a virtual env. FreeBSD em0 (192.168.0.1) - OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 (192.168.1.1) - OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) - OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) - OpenBSD#4 em0 (192.168.3.2) FreeBSD em4 (192.168.4.1) - OpenBSD#5 em1 (192.168.4.2) ipfw rule: fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 Then a ping 192.168.1.2 was issued from OpenBSD#5. Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The packet successfully arrived at OpenBSD#1, where it was discarded, and at OpenBSD#2, where it got its reply. Only these combinations of interface direction do not duplicate the packet: out xmit fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 and fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 Even out recv em4 xmit em1 leads to packet duplication. I think that it is a bad thing for PBR. As I can see from these tests, I can not use all the options to do PBR. In my real needs I have to: 1. let web traffic flow to an cache appliance (from internal network to cache, from internet to cache) 2. do NAT for the internal network under three different links In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But I am hitting my head in the wall for almost three weeks on this, only now I have the time to test in a more clear way. First I blamed the NAT, after that the one_pass=0, and now, with these results, well... Someone has an explanation about it? Something related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? For my real needs, I figured out that it works with ...before NAT aliasing... fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE ...after NAT dealiasing... fwd CACHE_IP proto tcp dst-ip table(INT) src-port 80 out recv EXT_IFACE But I am not confident that it will remains in good shape without knowing exactly why fwd behaves that way. Thank you in advance for your time, Raimundo Santos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Intel DPDK added to FreeBSD ports collection
On Oct 29, 2014, at 05:13, Eggert, Lars l...@netapp.com wrote: Hi, On 2014-10-20, at 17:40, Jim Harris jimhar...@freebsd.org wrote: Just wanted to send a heads-up that Intel's Data Plane Development Kit (DPDK) for high speed packet processing was added to the FreeBSD ports collection last week under net/dpdk. ... For any questions, please check out dpdk.org and the developer mailing list (d...@dpdk.org). that list seems to be more about the development of the kit, rather that about using the kit? I've started to play with DPDK under FreeBSD, and am getting the following warning: EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is not available - clock timings may be less accurate. This is with the HPET changes rpaulo@ recently committed, and /dev/hpet0 is present. I still haven't fixed DPDK to use /dev/hpet0. Can you add a symbolic link /dev/hpet0 - /dev/hpet? -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Intel DPDK added to FreeBSD ports collection
On Wed, Oct 29, 2014 at 8:41 AM, Rui Paulo rpa...@me.com wrote: On Oct 29, 2014, at 05:13, Eggert, Lars l...@netapp.com wrote: Hi, On 2014-10-20, at 17:40, Jim Harris jimhar...@freebsd.org wrote: Just wanted to send a heads-up that Intel's Data Plane Development Kit (DPDK) for high speed packet processing was added to the FreeBSD ports collection last week under net/dpdk. ... For any questions, please check out dpdk.org and the developer mailing list (d...@dpdk.org). that list seems to be more about the development of the kit, rather that about using the kit? d...@dpdk.org is mostly development related, but I have seen lots of questions like yours on the list too. I've started to play with DPDK under FreeBSD, and am getting the following warning: EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is not available - clock timings may be less accurate. This is with the HPET changes rpaulo@ recently committed, and /dev/hpet0 is present. I still haven't fixed DPDK to use /dev/hpet0. Can you add a symbolic link /dev/hpet0 - /dev/hpet? This is certainly one problem, but it also looks like DPDK should spit out an error message when it cannot open /dev/hpet. So I suspect CONFIG_RTE_LIBEAL_USE_HPET needs to be set to 'y' as well in your config file. -Jim -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers
On Oct 28, 2014, at 12:41, Sean Bruno sbr...@ignoranthack.me wrote: It looks like recent HEAD seems to fail intermittently here on my home network. It will recover, but urtwn(4) seems to lose an ack or something on txmit. turning on debug, yields this message during the hang event. hw.usb.urtwn.debug: 1 Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue That means the firmware is stuck and is holding transmit buffers, so we have no more in the unused list. Additionally, I get the following at module load time: urtwn0: vendor 0x0bda product 0x8176, class 0/0, rev 2.00/2.00, addr 1 on usbus0 urtwn0: could not read efuse byte at address 0x10 urtwn0: could not read efuse byte at address 0x18 I'm not sure what this is. -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ipfw fwd duplicating packets in 9.3-RELEASE
On 29 October 2014 12:53, bycn82 byc...@gmail.com wrote: Hi, I cannot help to point out when the ICMP packet was duplicated and transfer via 2 different links, If it happens in my machine, I will call this feature multi-homing. That is a bit off topic, but how and undesired behaviour could be a feature? It is not only undesired, but it is also undocumented. If I filter incoming packtes, I got it sent to the original and to the fwd destinations, by my tests. I can not see how it is multi-homing. What I know by multi-homing is: two or more interconnections with the same other network, or to the Internet. It implies more care to the outgoing and incoming paths. Who leaves from link 1 will enter via link 1? It is ok to happen that way? Only the context can say that. In my case the packet not only get out via two different links, but it is reaching two *different* machines in different networks. But what I want to say is the firewall rule fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 You can remove the out because xmit will check the out interface. Thank you for the clarification. Regards, Bycn82 Regards, Raimundo Santos -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Raimundo Santos Sent: Tuesday, 28 October, 2014 3:32 PM To: freebsd-net@freebsd.org Subject: ipfw fwd duplicating packets in 9.3-RELEASE Hello list! I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, latest updates, GENERIC kernel, in this setup: 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as network machines, each one connected to FreeBSD via one port. It is a virtual env. FreeBSD em0 (192.168.0.1) - OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 (192.168.1.1) - OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) - OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) - OpenBSD#4 em0 (192.168.3.2) FreeBSD em4 (192.168.4.1) - OpenBSD#5 em1 (192.168.4.2) ipfw rule: fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 Then a ping 192.168.1.2 was issued from OpenBSD#5. Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The packet successfully arrived at OpenBSD#1, where it was discarded, and at OpenBSD#2, where it got its reply. Only these combinations of interface direction do not duplicate the packet: out xmit fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 and fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 Even out recv em4 xmit em1 leads to packet duplication. I think that it is a bad thing for PBR. As I can see from these tests, I can not use all the options to do PBR. In my real needs I have to: 1. let web traffic flow to an cache appliance (from internal network to cache, from internet to cache) 2. do NAT for the internal network under three different links In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But I am hitting my head in the wall for almost three weeks on this, only now I have the time to test in a more clear way. First I blamed the NAT, after that the one_pass=0, and now, with these results, well... Someone has an explanation about it? Something related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? For my real needs, I figured out that it works with ...before NAT aliasing... fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE ...after NAT dealiasing... fwd CACHE_IP proto tcp dst-ip table(INT) src-port 80 out recv EXT_IFACE But I am not confident that it will remains in good shape without knowing exactly why fwd behaves that way. Thank you in advance for your time, Raimundo Santos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Very bad Realtek problems
On Wed, Oct 29, 2014 at 10:46:30AM +0900, Yonghyeon PYUN wrote: Given that you can reliably reproduce the issue, let's check simple ones first. Just as a quick update, I couldn't tolerate the network outages any more as they were impacting my work, so I bought an Intel NIC. That said, this will actually free me up to do more debugging of the Realtek as soon as I get a chance to finish setting up a small test network - I'll be able to look at both sides of interactions instead of depending on the flaky interface. If you think the issue intermittently happens regardless of network load, try attached patch. I'm not sure whether the patch makes any difference for you since many PCIe NICs don't implement CLKREQ feature. It's just a wild guess. This is an onboard NIC, for what it's worth, on my: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M Version: Rev X.0x I'm not sure if that changes it as compared with a plug-in PCIe device. Just mentioning it for completeness. -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
inet_pton() broken
inet_pton() has regressed to a primitive form that doesn't support hex or
octal, at least for ipv4. This breaks at least gethostbyname() on hosts
in /etc/hosts.
/etc/hosts is still documented as supporting the general form and as
using [sic] inet_addr(3):
%Network addresses are specified in the conventional ``.'' (dot) notation
%using the inet_addr(3) routine from the Internet address manipulation
%library, inet(3). Host names may contain any printable character other
%than a field delimiter, newline, or comment character.
This documentation hasn't changed since 4.4BSD. 4.4BSD doesn't even
have inet_pton(). It actually uses inet_aton() in gethostbyname(),
but inet_aton() is just a inet_addr(3) with a modified API. FreeBSD
has used inet_pton() in gethostent() for a long time. It used to work.
The format of inet_pton() is undocumented in FreeBSD, except to say that
it doesn't support shortened addresses:
%The inet_pton() function converts a presentation format address (that is,
%printable form as held in a character string) to network format (usually
%a struct in_addr or some other internal binary representation, in network
%byte order). It returns 1 if the address was valid for the specified
%address family, or 0 if the address was not parseable in the specified
%address family, or -1 if some system error occurred (in which case errno
%will have been set). This function is presently valid for AF_INET and
%AF_INET6.
%
% STANDARDS
%The inet_ntop() and inet_pton() functions conform to X/Open Networking
%Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept
%1-, 2-, or 3-part dotted addresses; all four parts must be specified and
%are interpreted only as decimal values. This is a narrower input set
%than that accepted by inet_aton().
POSIX.1-2001 specifies both in_addr() and inet_pton(), but not inet_aton().
Unlike the above, it says what the format for inet_pton() is -- for ipv4,
it is just decimal dotted with all 4 components required.
So the bug is in gethostbyname() still using inet_pton() after it regressed
to be broken to X/Open/POSIX spec.
Many programs don't have this bug. The bug broke ifconfig on hosts by
name with the names in /etc/hosts (I use some small octal numbers there
to line up fields). It was confusing for ifconfig to work for the
same addresses that it doesn't work on, then the addresses are given
on the command line instead of in /etc/hosts.
In /usr/src/*bin, there are now 61 references to inet_pton(), 28 to
inet_aton() and 18 to inet_ntoa(). In a 10 year old soure tree where
inet_pton() was not broken to spec, there were 35 to inet_pton(), 26 to
inet_aton() and 30 to inet_addr(). It looks like there are just a few
more ipv6 applications and most inet_aton()s are unchanged, but half
the inet_addr()s were changed to the incompatible inet_pton() instead
of to the compatible inet_aton().
Indeed, many of the new inet_pton()'s are in mountd, nfsd and rpc.statd.
This might break /etc/exports files like /etc/hosts. The format of
addresses is more or less documented in exports(5) as being the
inet_addr(3) format for ipv4 but more restricted for ipv6:
%The third component of a line specifies the host set to which the line
%applies. The set may be specified in three ways. The first way is to
%list the host name(s) separated by white space. (Standard Internet
%``dot'' addresses may be used in place of names.) The second way is to
%
% EXAMPLES
% ...
% /u -maproot=bin: -network 131.104.48 -mask 255.255.255.0
Network addresses are special and use the reduced format. This cannot
be parsed by inet_pton(). This probably still works, because there is
an RFC related to the bug I am reporting, and the code follows the RFC
to avoid regressions in the ipv4 case: mountd parses -network addr
by checking for a hex digit in addr; then it calls getaddrinfo(),
which has:
% switch (afd-a_af) {
% case AF_INET:
% /*
%* RFC3493 requires getaddrinfo() to accept AF_INET formats
%* that are accepted by inet_addr() and its family. The
%* accepted forms includes the classful one, which inet_pton
%* does not accept. So we need to separate the case for
%* AF_INET.
%*/
% if (inet_aton(hostname, (struct in_addr *)pton) != 1)
% return 0;
% break;
% default:
% if (inet_pton(afd-a_af, hostname, pton) != 1)
% return 0;
% break;
% }
Old versions had the AF_INET case under #if 1 with the cryptic comment
/*X/Open Spec*/ (does that mean not broken to spec?).
% ...
%The file system rooted at /a is also exported to the IPv6 network
%3ffe:1ce1:1:fe80:: address, using the upper 64 bits as the prefix. Note
%that, unlike with IPv4 network
Re: Very bad Realtek problems
On Wed, Oct 29, 2014 at 01:01:26PM -0400, Mason Loring Bliss wrote: On Wed, Oct 29, 2014 at 10:46:30AM +0900, Yonghyeon PYUN wrote: Given that you can reliably reproduce the issue, let's check simple ones first. Just as a quick update, I couldn't tolerate the network outages any more as they were impacting my work, so I bought an Intel NIC. That said, this will actually free me up to do more debugging of the Realtek as soon as I get a chance to finish setting up a small test network - I'll be able to look at both sides of interactions instead of depending on the flaky interface. Ok, if you happen to find spare time on testing, let me know your findings. If you think the issue intermittently happens regardless of network load, try attached patch. I'm not sure whether the patch makes any difference for you since many PCIe NICs don't implement CLKREQ feature. It's just a wild guess. This is an onboard NIC, for what it's worth, on my: Yes, it's very common to see LOM version in these days. Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M Version: Rev X.0x I'm not sure if that changes it as compared with a plug-in PCIe device. Just mentioning it for completeness. There is no much difference for driver between LOM and standalone NIC. LOM version may have some modifications compared to engineering samples I have. And motherboard vendors are free to program EEPROM/FLASH of NIC to meet their needs. I don't think the motherboard vendor heavily changed the NIC configuration though. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 188032] [lo] IPv6 on lo never leaves 'tentative' state if configured with prefixlen 128
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188032 Hiroki Sato h...@freebsd.org changed: What|Removed |Added CC||h...@freebsd.org Assignee|freebsd-net@FreeBSD.org |h...@freebsd.org --- Comment #9 from Hiroki Sato h...@freebsd.org --- Take. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers
On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: It looks like recent HEAD seems to fail intermittently here on my home network. It will recover, but urtwn(4) seems to lose an ack or something on txmit. turning on debug, yields this message during the hang event. hw.usb.urtwn.debug: 1 Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue Additionally, I get the following at module load time: urtwn0: vendor 0x0bda product 0x8176, class 0/0, rev 2.00/2.00, addr 1 on usbus0 urtwn0: could not read efuse byte at address 0x10 urtwn0: could not read efuse byte at address 0x18 Strange. What the wlan dongle model do you use? I have the RTL8188CUS wireless usb adaptor (Edimax EW-7811Un), but I cannot reproduce that issue. Kevin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: performance of the swtich/case statements
Hi,
According to my understanding in Java programming, the compiler will
automatically store the values into a table and jump to the correct one
according to the value only when the condition values are in running
number,
for example.
swtich(a){
case 1: code block 1
case 2: code block 2
case 3: code block 3
case 4: code block 4
default: code block 5
}
it will be handled by an array
1--code block 1
2--code block 2
3--code block 3
4--code block 4
others--code block 5
so when the value N is greater than or lesser than 1, it will be directly
jump to the code block 5
otherwise, it will jump to N, because call the cases are nice in running
numbers,
but when the cases are messy, it will by just like lots of if/else
On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky
erichsfreebsdl...@alogt.com wrote:
Hi,
On Wed, 29 Oct 2014 22:39:34 +0800
bycn82 byc...@gmail.com wrote:
It is using the switch/case statement to make the code clear in the
I am not a C programmer, so I am not clear how the switch/case will be
optimized by the compiler in FreeBSD. But I used to write a compiler
by myself and I use a hash table to handle all the conditions in the
case statements because my compiler don't care about performance!,
But in C it is different, the case statement can only accept int
values, so I don't think it will use hash or what , it should be
directly use an array(), So whether it can be optimized it depends on
the conditions in the switch/case statements, and I noticed that the
cases statement in the 2 loops are not arranging the opcode in
running number, so does the compiler smart enough to optimize it?
I did not check recently. It was already a long, long time ago, that
compilers checked the limits and used the values as an index into a
table to jump to the code. I hope that this did not get changed.
With other words, the order in the code does not matter. The only
optimisation the compiler can do, is not to use a table if the
statement consists of a low number of entries only.
Erich
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
