Searched hist:155 (Results 1 - 25 of 35) sorted by relevance

12

/freebsd-10.1-release/sys/dev/patm/genrtab/
H A Dgenrtab.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A DMakefile117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
/freebsd-10.1-release/sys/dev/patm/
H A Didt77252reg.h117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_rtables.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patmvar.h117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_intr.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_ioctl.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_rx.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_attach.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
H A Dif_patm_tx.c117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
/freebsd-10.1-release/sys/modules/patm/
H A DMakefile117632 Tue Jul 15 09:57:24 MDT 2003 harti This is a driver for IDT77252 based ATM interfaces. It has been tested
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).

Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
/freebsd-10.1-release/lib/msun/ld128/
H A Ds_exp2l.cdiff 176231 Wed Feb 13 08:44:44 MST 2008 bde Fix exp2*(x) on signaling NaNs by returning x+x as usual.

This has the side effect of confusing gcc-4.2.1's optimizer into more
often doing the right thing. When it does the wrong thing here, it
seems to be mainly making too many copies of x with dependency chains.
This effect is tiny on amd64, but in some cases on i386 it is enormous.
E.g., on i386 (A64) with -O1, the current version of exp2() should
take about 50 cycles, but took 83 cycles before this change and 66
cycles after this change. exp2f() with -O1 only speeded up from 51
to 47 cycles. (exp2f() should take about 40 cycles, on an Athlon in
either i386 or amd64 mode, and now takes 42 on amd64). exp2l() with
-O1 slowed down from 155 cycles to 123 for some args; this is unimportant
since the i386 exp2l() is a fake; the wrong thing for it seems to
involve branch misprediction.
/freebsd-10.1-release/lib/msun/ld80/
H A Ds_exp2l.cdiff 176231 Wed Feb 13 08:44:44 MST 2008 bde Fix exp2*(x) on signaling NaNs by returning x+x as usual.

This has the side effect of confusing gcc-4.2.1's optimizer into more
often doing the right thing. When it does the wrong thing here, it
seems to be mainly making too many copies of x with dependency chains.
This effect is tiny on amd64, but in some cases on i386 it is enormous.
E.g., on i386 (A64) with -O1, the current version of exp2() should
take about 50 cycles, but took 83 cycles before this change and 66
cycles after this change. exp2f() with -O1 only speeded up from 51
to 47 cycles. (exp2f() should take about 40 cycles, on an Athlon in
either i386 or amd64 mode, and now takes 42 on amd64). exp2l() with
-O1 slowed down from 155 cycles to 123 for some args; this is unimportant
since the i386 exp2l() is a fake; the wrong thing for it seems to
involve branch misprediction.
/freebsd-10.1-release/lib/msun/src/
H A Ds_exp2.cdiff 176231 Wed Feb 13 08:44:44 MST 2008 bde Fix exp2*(x) on signaling NaNs by returning x+x as usual.

This has the side effect of confusing gcc-4.2.1's optimizer into more
often doing the right thing. When it does the wrong thing here, it
seems to be mainly making too many copies of x with dependency chains.
This effect is tiny on amd64, but in some cases on i386 it is enormous.
E.g., on i386 (A64) with -O1, the current version of exp2() should
take about 50 cycles, but took 83 cycles before this change and 66
cycles after this change. exp2f() with -O1 only speeded up from 51
to 47 cycles. (exp2f() should take about 40 cycles, on an Athlon in
either i386 or amd64 mode, and now takes 42 on amd64). exp2l() with
-O1 slowed down from 155 cycles to 123 for some args; this is unimportant
since the i386 exp2l() is a fake; the wrong thing for it seems to
involve branch misprediction.
H A Ds_exp2f.cdiff 176231 Wed Feb 13 08:44:44 MST 2008 bde Fix exp2*(x) on signaling NaNs by returning x+x as usual.

This has the side effect of confusing gcc-4.2.1's optimizer into more
often doing the right thing. When it does the wrong thing here, it
seems to be mainly making too many copies of x with dependency chains.
This effect is tiny on amd64, but in some cases on i386 it is enormous.
E.g., on i386 (A64) with -O1, the current version of exp2() should
take about 50 cycles, but took 83 cycles before this change and 66
cycles after this change. exp2f() with -O1 only speeded up from 51
to 47 cycles. (exp2f() should take about 40 cycles, on an Athlon in
either i386 or amd64 mode, and now takes 42 on amd64). exp2l() with
-O1 slowed down from 155 cycles to 123 for some args; this is unimportant
since the i386 exp2l() is a fake; the wrong thing for it seems to
involve branch misprediction.
/freebsd-10.1-release/sys/dev/sound/pci/
H A Demu10k1.cdiff 153799 Wed Dec 28 15:57:36 MST 2005 netchild Fix the order of the stereo channels (left <-> right).

From the PR:
---snip---
I think I have found the change which reversed the channels.
Revision 1.44 of emu10k1.c, which added Audigy support, has the line

emu_wrptr(sc, v->vnum, FXRT, 0xd01c0000);

replaced with the following lines:

if (sc->audigy) {
emu_wrptr(sc, v->vnum, A_FXRT1, v->fxrt1);
emu_wrptr(sc, v->vnum, A_FXRT2, v->fxrt2);
emu_wrptr(sc, v->vnum, A_SENDAMOUNTS, 0);
}
else
emu_wrptr(sc, v->vnum, FXRT, v->fxrt1 << 16);

where v->fxrt1 << 16 == 0xd10c0000

I don't have Audigy, so I'm not sure if the problem affects Audigy cards
too. The order of the channels can't be tested by just altering mixer
settings. Here's a small program to test if the channels are reversed on
your sound card:

#include <sys/soundcard.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
int fd = open("/dev/dsp", O_WRONLY), format = AFMT_S16_LE;
int channels = 2, rate = 22050, i;

/* 450 Hz sine wave on left channel, right channel silent */
unsigned char samples[] = {0, 0, 0, 0, 94, 16, 0, 0, 120, 32, 0, 0,
9, 48, 0, 0, 208, 62, 0, 0, 143, 76, 0, 0, 12, 89, 0, 0, 19, 100,
0, 0, 117, 109, 0, 0, 11, 117, 0, 0, 182, 122, 0, 0, 92, 126, 0,
0, 239, 127, 0, 0, 105, 127, 0, 0, 202, 124, 0, 0, 32, 120, 0, 0,
124, 113, 0, 0, 251, 104, 0, 0, 193, 94, 0, 0, 249, 82, 0, 0,
212, 69, 0, 0, 138, 55, 0, 0, 85, 40, 0, 0, 120, 24, 0, 0, 51, 8,
0, 0, 205, 247, 0, 0, 136, 231, 0, 0, 171, 215, 0, 0, 118, 200,
0, 0, 44, 186, 0, 0, 7, 173, 0, 0, 63, 161, 0, 0, 5, 151, 0, 0,
132, 142, 0, 0, 224, 135, 0, 0, 54, 131, 0, 0, 151, 128, 0, 0,
17, 128, 0, 0, 164, 129, 0, 0, 74, 133, 0, 0, 245, 138, 0, 0,
139, 146, 0, 0, 237, 155, 0, 0, 244, 166, 0, 0, 113, 179, 0, 0,
48, 193, 0, 0, 247, 207, 0, 0, 136, 223, 0, 0, 162, 239, 0, 0};

ioctl(fd, SNDCTL_DSP_SETFMT,&format);
ioctl(fd, SNDCTL_DSP_CHANNELS,&channels);
ioctl(fd, SNDCTL_DSP_SPEED,&rate);

for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));
write(fd, &samples, 2); /* swap channels */
for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));

return 0;
}

You should hear a sound on the left channel followed by a sound on the
right channel. If you hear a sound on the right channel first, the
channels are reversed.
---snip---

Owners of an audigy card should verify if it DTRT and report back.

Noticed by: Matthias Buelow <mkb@mukappabeta.de>
Submitted by: Juha-Matti Tilli <juhis@nallukka.net>
PR: 72221
/freebsd-10.1-release/sys/sys/
H A Deventhandler.hdiff 243631 Tue Nov 27 19:36:13 MST 2012 andre Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.

The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.

At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.

Tidy up ordering in init_param2() and check up on some users of
those values calculated here.

Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.

Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.

The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.

NB: Every cluster also has an mbuf associated with it.

Two examples on the revised mbuf sizing limits:

1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters

16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters

These defaults should be sufficient for even the most demanding
network loads.

MFC after: 1 month
H A Dsocket.hdiff 39271 Tue Sep 15 09:44:44 MDT 1998 phk (this is an extract from src/share/examples/atm/README)

===================================
HARP | Host ATM Research Platform
===================================

HARP 3

What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.

HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.

HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.

HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:

o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol

What's supported
----------------
The following are supported by HARP 3:

o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters

o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)

o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"

o ATM Sockets interface
- The file atm-sockets.txt contains further information

What's not supported
--------------------
The following major features of the above list are not currently supported:

o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters

This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).

Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
/freebsd-10.1-release/sys/kern/
H A Dkern_mbuf.cdiff 243631 Tue Nov 27 19:36:13 MST 2012 andre Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.

The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.

At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.

Tidy up ordering in init_param2() and check up on some users of
those values calculated here.

Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.

Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.

The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.

NB: Every cluster also has an mbuf associated with it.

Two examples on the revised mbuf sizing limits:

1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters

16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters

These defaults should be sufficient for even the most demanding
network loads.

MFC after: 1 month
H A Dsubr_param.cdiff 243631 Tue Nov 27 19:36:13 MST 2012 andre Base the mbuf related limits on the available physical memory or
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.

The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.

At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.

Tidy up ordering in init_param2() and check up on some users of
those values calculated here.

Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.

Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.

The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.

NB: Every cluster also has an mbuf associated with it.

Two examples on the revised mbuf sizing limits:

1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters

16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters

These defaults should be sufficient for even the most demanding
network loads.

MFC after: 1 month
/freebsd-10.1-release/sbin/
H A DMakefilediff 39271 Tue Sep 15 09:44:44 MDT 1998 phk (this is an extract from src/share/examples/atm/README)

===================================
HARP | Host ATM Research Platform
===================================

HARP 3

What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.

HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.

HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.

HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:

o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol

What's supported
----------------
The following are supported by HARP 3:

o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters

o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)

o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"

o ATM Sockets interface
- The file atm-sockets.txt contains further information

What's not supported
--------------------
The following major features of the above list are not currently supported:

o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters

This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).

Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
/freebsd-10.1-release/etc/mtree/
H A DBSD.include.distdiff 39271 Tue Sep 15 09:44:44 MDT 1998 phk (this is an extract from src/share/examples/atm/README)

===================================
HARP | Host ATM Research Platform
===================================

HARP 3

What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.

HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.

HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.

HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:

o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol

What's supported
----------------
The following are supported by HARP 3:

o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters

o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)

o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"

o ATM Sockets interface
- The file atm-sockets.txt contains further information

What's not supported
--------------------
The following major features of the above list are not currently supported:

o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters

This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).

Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
/freebsd-10.1-release/include/
H A DMakefilediff 39271 Tue Sep 15 09:44:44 MDT 1998 phk (this is an extract from src/share/examples/atm/README)

===================================
HARP | Host ATM Research Platform
===================================

HARP 3

What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.

HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.

HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.

HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:

o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol

What's supported
----------------
The following are supported by HARP 3:

o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters

o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)

o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"

o ATM Sockets interface
- The file atm-sockets.txt contains further information

What's not supported
--------------------
The following major features of the above list are not currently supported:

o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters

This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).

Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
/freebsd-10.1-release/lib/
H A DMakefilediff 39271 Tue Sep 15 09:44:44 MDT 1998 phk (this is an extract from src/share/examples/atm/README)

===================================
HARP | Host ATM Research Platform
===================================

HARP 3

What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.

HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.

HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.

HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:

o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol

What's supported
----------------
The following are supported by HARP 3:

o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters

o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)

o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"

o ATM Sockets interface
- The file atm-sockets.txt contains further information

What's not supported
--------------------
The following major features of the above list are not currently supported:

o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters

This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).

Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.

Completed in 490 milliseconds

12