Searched hist:155 (Results 1 - 25 of 35) sorted by relevance
/freebsd-10.1-release/sys/dev/patm/genrtab/ | ||
H A D | genrtab.c | 117632 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 D | Makefile | 117632 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 D | idt77252reg.h | 117632 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 D | if_patm_rtables.c | 117632 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 D | if_patmvar.h | 117632 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 D | if_patm_intr.c | 117632 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 D | if_patm_ioctl.c | 117632 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 D | if_patm_rx.c | 117632 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 D | if_patm.c | 117632 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 D | if_patm_attach.c | 117632 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 D | if_patm_tx.c | 117632 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 D | Makefile | 117632 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 D | s_exp2l.c | diff 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 D | s_exp2l.c | diff 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 D | s_exp2.c | diff 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 D | s_exp2f.c | diff 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 D | emu10k1.c | diff 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 D | eventhandler.h | diff 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 D | socket.h | diff 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 D | kern_mbuf.c | diff 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 D | subr_param.c | diff 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 D | Makefile | diff 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 D | BSD.include.dist | diff 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 D | Makefile | diff 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 D | Makefile | diff 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