mbuf allocation fails, and fix (i hope) a couple of style bugs.
I believe these printf() are extremely dangerous because now they can
occur on every incoming packet and are not rate limited. They were
meant to warn the sysadmin about lack of resources, but now they
can become a nice way to panic your system under load.
Other drivers (e.g. the fxp driver) have nothing like this.
There is a pending discussion on putting this kind of warnings
elsewhere, and I hope we can fix this soon.
underlying unaligned bcopy) on incoming packets that are already
available (albeit unaligned) in a buffer.
The performance improvement varies, depending on CPU and memory
speed, but can be quite large especially on slow CPUs. I have seen
over 50% increase on forwarding speed on the sis driver for the
486/133 (embedded systems), which does exactly the same thing.
The behaviour is controlled by a sysctl variable, hw.dc_quick which
defaults to 1. Set it to 0 to restore the old behaviour.
After running a few experiments (in userland, though) I am convinced
that doing the m_devget() is detrimental to performance in almost
all cases.
Even if your CPU has degraded performance with misaligned data,
the bcopy() in the driver has the same overhead due to misaligment
as the one that you save in the uiomove(), plus you do one extra
copy and pollute the cache.
But more often than not, you do not even have to touch the payload,
e.g. when you are forwarding packets, and even in the often-cited
case of NFS, you often end up passing a pointer to the payload to
the disk controller.
In any case, you can play with the sysctl variable to toggle between
the two behaviours, and see if it makes a difference.
MFC-after: 3 days
STANDARDS section of the page. Add one remark there about inet_pton(3)
only understanding decimal values (in contrast to inet_aton(3) and
friends who are happy with 0ac.020.25 for 172.16.0.25).
Caught by: ru
MFC after: 2 days
only once into an array of shell variables, and then scan the array
to find entries matching the MAC address.
Associative arrays would really be handy here...
The definition of character class digit requires that only ten characters
-the ones defining digits- can be specified; alternate digits (for
example, Hindi or Kanji) cannot be specified here. However, the encoding
may vary if an implementation supports more than one encoding.
The definition of character class xdigit requires that the characters
included in character class digit are included here also and allows for
different symbols for the hexadecimal digits 10 through 15.
readability.
o Conditionalize only the SYSCTL definitions for the regression
tree, not the variables itself, decreasing the number of #ifdef
REGRESSIONs scattered in kern_mib.c, and making the code more
readable.
Sponsored by: DARPA, NAI Labs
the following functions in the following commits:
- atoll() in revs 1.23-1.25
- llabs() and lldiv() in revs 1.22
- strtoq() and strtouq() in revs 1.18
C99 functions must not be declared in C90/POSIX.1-1990 sections, and
"long long" must not be exposed to compilers that don't support it.
Fixed style bugs (mainly misindentation and disorder) related the
following functions in the following commits:
- atoll() in revs 1.23-1.25
- getprogname() in rev.1.21
- sranddev() in revs 1.19-1.20
- strtoq() and strtouq() in rev.1.13
- user_from_uid() in rev.1.1
Breakage of K&R and C90 support used to be avoided by conditializing the
"long long"s for strtoq() and strtouq() on __STRICT_ANSI__, but the
conditionals should have gone away in rev.1.13 when the "long long"s went
away (the problem was moved to the places that declare quad_t and u_quad_t).
handed a integer, not void).
- No need to set flags to zero when they already will be.
- It was also noted the manner in which the signal handling has changed
might possibly generate some problems (hangs possibly) -- these, while
remaining in the code, will be fixed shortly (within a day).
Submitted by: bde
have alignment problems.
On small boxes (e.g. the net4501 from Soekris, featuring a 486/133)
this provides huge performance benefits: the peak forwarding rate
with avg.sized packets goes up by 50-70% because of this change
alone. Faster CPUs might benefit less from this change, but in any
case the CPU has better things to do than waste time on useless
memory-to-memory copies.
Several drivers (for Tulip-like cards) might benefit from a similar
change.
Right now the new behaviour is controlled by a sysctl variable,
hw.sis_quick which defaults to 1 (on), you can set it to 0 to
reintroduce the old behaviour (and compare the results). The
variable is only there to show how much you can gain with this
change, it will go away soon.
Also, slightly simplify the code to initialize the ring buffers,
and remove a couple of dangerous printf's which could trigger on
any packet in case of mbuf shortage.
MFC-after: 3 days
the return code and errno instead. Those warnings did not do any good
for daemonized users of initgroups(3), and confused cvs clients that
communicated with non-root cvs pserver.
The committed fix differs from the one suggested in the PR, and was
submitted by ru.
PR: 15421
Approved by: markm
Discussed on: -stable, -current at various times
