RE: Gig-E performance with FreeBSD
I am the manager of the kernel group at Sitara Networks and we have tested both Netgear and Intel GigE cards. The Tigon based Netgear card is not as good as the Intel 543 based card. The Tigon chip maxes out at 200k packets/second. The Intel 543 does better by about 30%. Charles Richmond Original Message- >From: "Kevin Oberman" <[EMAIL PROTECTED]> >To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >Cc: >Bcc: >Subj: Gig-E performance with FreeBSD >Type: IPM.Note >Sent: Wednesday, August 29, 2001 4:12 PM > >Has anyone done any performance testing of Gig-E cards on FreeBSD? I >need to run them with some high performance apps and I'm wondering what >sort of performance people have been able to get, assuming large >windows (up to 8 MB), with and without jumbo frames. > >Does anyone have any experience in this area? > >Thanks, > >R. Kevin Oberman, Network Engineer >Energy Sciences Network (ESnet) >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Help with IPSec VPN
Hi all, I've been trying to get an IPSec tunneling VPN between two boxes working without much success. I've read the FAQs and HOWTOs on www.freebsd.org, www.freebsddiary.org, www.daemonnews.org and www.kame.net and they all have helped me get closer to where I want to be, but I'm still missing something. The exact problem that I'm running into is that once I've got everything configured (all details below), when I try and ping the other end of the tunnel, nothing happens. I get this from 'netstat -p ipsec', with every other ipsec counter showing a value of 0. 8 outbound packets with no SA available Both boxes are running RELENG_4_3 (security release), and have 'options IPSEC' and 'options IPSEC_ESP' in the kernel. Box A is 192.168.0.2/24, Box B is 192.168.0.3/24. Here's what I'm doing on box A: gabby# gifconfig gif0 192.168.0.2 192.168.0.3 gabby# ifconfig gif0 inet 10.0.2.1 10.0.3.1 netmask 255.255.255.0 gabby# setkey -F gabby# setkey -FP gabby# setkey -c << EOF add 10.0.2.1 10.0.3.1 esp 1000 -E 3des-cbc "goofgoofgoofgoofgoofgoof"; add 10.0.3.1 10.0.2.1 esp 1001 -E 3des-cbc "foolfoolfoolfoolfoolfool"; spdadd 10.0.2.0/24 10.0.3.0/24 any -P out ipsec esp/tunnel/192.168.0.2-192.168.0.3/require; spdadd 10.0.3.0/24 10.0.2.0/24 any -P in ipsec esp/tunnel/192.168.0.3-192.168.0.2/require; EOF gabby# route add -net 10.0.3.0/24 10.0.3.1 gabby# I'm doing the exact same thing on Box B, except that all the IP pairs are reversed, with the exception of the 'add' lines for setkey (as outlined in the KAME IpSec FAQ, VPN tunnel section.) and the route statement. Here's output from gifconfig, ifconfig, netstat, and setkey (slightly trimmed): gabby# gifconfig -a gif0 gif0: flags=8011 mtu 1280 inet6 fe80::200:c0ff:fef2:7c40%gif0 --> :: prefixlen 64 inet 10.0.2.1 --> 10.0.3.1 netmask 0xff00 physical address inet 192.168.0.2 --> 192.168.0.3 gabby# ifconfig gif0 gif0: flags=8011 mtu 1280 inet6 fe80::200:c0ff:fef2:7c40%gif0 --> :: prefixlen 64 scopeid 0x4 inet 10.0.2.1 --> 10.0.3.1 netmask 0xff00 gabby# netstat -rn -f inet DestinationGatewayFlags Refs Use Netif Expire default192.168.0.1UGSc10 ed0 10.0.3/24 10.0.3.1 UGSc00 gif0 10.0.3.1 10.0.2.1 UH 18 gif0 127.0.0.1 127.0.0.1 UH 1 92 lo0 192.168link#1 UC 00 ed0 => gabby# setkey -D 10.0.3.1 10.0.2.1 esp mode=any spi=1001(0x03e9) reqid=0(0x) E: 3des-cbc 666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c replay=0 flags=0x0040 state=mature seq=1 pid=403 created: Aug 31 08:39:59 2001 current: Aug 31 09:11:49 2001 diff: 1910(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 refcnt=1 10.0.2.1 10.0.3.1 esp mode=any spi=1000(0x03e8) reqid=0(0x) E: 3des-cbc 676f6f66 676f6f66 676f6f66 676f6f66 676f6f66 676f6f66 replay=0 flags=0x0040 state=mature seq=0 pid=403 created: Aug 31 08:39:59 2001 current: Aug 31 09:11:49 2001 diff: 1910(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 refcnt=1 gabby# setkey -DP 10.0.3.0/24[any] 10.0.2.0/24[any] any in ipsec esp/tunnel/192.168.0.3-192.168.0.2/require spid=4 seq=1 pid=404 refcnt=1 10.0.2.0/24[any] 10.0.3.0/24[any] any out ipsec esp/tunnel/192.168.0.2-192.168.0.3/require spid=3 seq=0 pid=404 refcnt=1 -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Tuning UDP for NFS
Howdy! I am interested in tuning UDP for NFS over a 100Mbs LAN. Specifically, to tune UDP, what are guidelines/restrictions for setting the sysclt variables net.inet.udp.maxdgram net.inet.udp.recvspace I assume that increasing both of these will improve performance. Is this correct? What factors should be considered, and what other barriers/effects (if any) will I come up against. Any experience/knowledge that you can share will be greatly appreciated. thanx - steve (Please CC me as I am not on the list) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Tuning UDP for NFS
< said: > net.inet.udp.maxdgram > net.inet.udp.recvspace > I assume that increasing both of these will improve performance. Neither of these have any impact on UDP performance. In fact, there really are no UDP performance parameters to be tweaked; the UDP protocol doesn't have much in the way of mechanism which would need it. You need to instead look at tuning NFS. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Tuning UDP for NFS
* Steve Shorter <[EMAIL PROTECTED]> [010831 12:14] wrote: > Howdy! > > I am interested in tuning UDP for NFS over a 100Mbs LAN. > > Specifically, to tune UDP, what are guidelines/restrictions for > setting the sysclt variables > > net.inet.udp.maxdgram > > net.inet.udp.recvspace > > > I assume that increasing both of these will improve performance. > Is this correct? What factors should be considered, and what other > barriers/effects (if any) will I come up against. > > Any experience/knowledge that you can share will be greatly > appreciated. Using UDP is usually a bad idea, I would use tcp, I find that these flags make for a decent mount point that's quite fast: rw,tcp,intr,nfsv3,-w=32768,-r=32768 -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Tuning UDP for NFS
In article <[EMAIL PROTECTED]>, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > > Using UDP is usually a bad idea, I would use tcp, I find that these > flags make for a decent mount point that's quite fast: > rw,tcp,intr,nfsv3,-w=32768,-r=32768 FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do you think we should change it? John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Tuning UDP for NFS
* John Polstra <[EMAIL PROTECTED]> [010831 15:03] wrote: > In article <[EMAIL PROTECTED]>, > Alfred Perlstein <[EMAIL PROTECTED]> wrote: > > > > Using UDP is usually a bad idea, I would use tcp, I find that these > > flags make for a decent mount point that's quite fast: > > rw,tcp,intr,nfsv3,-w=32768,-r=32768 > > FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do > you think we should change it? I'm not familiar with amd, what implications would that have? What worries me is people using amd against a v2 server, also those tunables are good at tickling bugs in other NFS implementations (as well as ours, at least a year or two ago). So if amd is smart enough to downgrade then yes, otherwise perhaps just a comment to indicate that the person may want to use better mount options... ? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
4.3 RELEASE "bug" status and patches?
Howdy! There is a reference to a networking code bug in 4.3 RELEASE on http://www.daemonnews.org/200108/benchmark.html in the footnote at the bottom. It also references a patch. I can find no other information about this issue. Can someone point me to the patch or other documentation about this. thanx - steve (Please Cc me as I am not on the list) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re:
>By the way, RFC2893 has the following text: (snip) >Thus, people would say that KAME (FreeBSD) is not compliant to RFC >2893. i guess you did not check the original question. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
PATCH: if_tap device cloning (final)
Hackers, Attached some patches that implements device cloning (with devfs(5) support) for tap(4). The implementation is based on resource manager (see tun(4) and gif(4)). Brooks Davis ([EMAIL PROTECTED]) took a quick look at the patch and seems has no objection. Please review, test and if there is no objection Brooks Davis will commit it. If there are any problems, please let me know. thanks, max p.s. i'm not on freebsd-net list, so please reply directly p.p.s. Brooks Davis wrote: [...] > Looks good. If could post a copy to freebsd-net and give it another > 24hrs or so for other responses, I'll commit it if nothing else comes > up. diff -ru /usr/src/share/man/man4/tap.4 ./src/share/man/man4/tap.4 --- /usr/src/share/man/man4/tap.4 Thu Aug 30 14:23:44 2001 +++ ./src/share/man/man4/tap.4 Thu Aug 30 15:14:40 2001 @@ -1,4 +1,4 @@ -.\" $FreeBSD: src/share/man/man4/tap.4,v 1.8 2001/08/07 15:48:39 ru Exp $ +.\" $FreeBSD: src/share/man/man4/tap.4,v 1.7 2001/05/01 09:15:13 schweikh Exp $ .\" Based on PR#2411 .\" .Dd July 9, 2000 @@ -36,11 +36,50 @@ interface. .Pp The network interfaces are named -.Sy tap Ns Ar 0 , -.Sy tap Ns Ar 1 , -etc, as many as were made by -.Xr MAKEDEV 8 . -Each one supports the usual Ethernet network-interface +.Dq Li tap0 , +.Dq Li tap1 , +etc., one for each control device that has been opened. +These Ethernet network interfaces persist until +.Pa if_tap.ko +module is unloaded (if +.Nm +is built into your kernel, the network interfaces can not be removed). +.Pp +On older systems without +.Xr devfs 5 +support, +.Xr MAKEDEV 8 +should be used to create the initial control devices and the task +of locating an unused device is left up to the opener (a +.Nm +device is usually obtained by attempting to open +.Pa /dev/tap0 , +and if that fails +.Pa /dev/tap1 +etc., until an +.Va errno +of +.Er EBUSY +is not received). +.Pp +On systems with +.Xr devfs 5 +support, +.Nm +permits opens on the special control device +.Pa /dev/tap . +When this device is opened, +.Nm +will return a handle for the lowest unused +.Nm +device (use +.Xr devname 3 +to determine which). +Control devices (once successfully opened) persist until +.Pa if_tap.ko +is unloaded in the same way that network interfaces persist (see above). +.Pp +Each interface supports the usual Ethernet network interface .Xr ioctl 2 Ns s , such as .Dv SIOCSIFADDR @@ -56,7 +95,7 @@ there); writing an Ethernet frame to the control device generates an input frame on the network interface, as if the -(non-existent) +.Pq non-existent hardware had just received it. .Pp The Ethernet tunnel device, normally @@ -91,15 +130,14 @@ .Fn write . Writes will not block; if the frame cannot be accepted for a transient reason -(e.g., no buffer space available), +.Pq e.g., no buffer space available , it is silently dropped; if the reason is not transient -(e.g., frame too large), +.Pq e.g., frame too large , an error is returned. The following .Xr ioctl 2 calls are supported -(defined in -.Aq Pa net/if_tap.h ) : +.Pq defined in Aq Pa net/if_tap.h Ns : .Bl -tag -width VMIO_SIOCSETMACADDR .It Dv TAPSDEBUG The argument should be a pointer to an @@ -115,7 +153,7 @@ Turn non-blocking I/O for reads off or on, according as the argument .Va int Ns 's value is or isn't zero -(Writes are always nonblocking). +.Pq Writes are always nonblocking . .It Dv FIOASYNC Turn asynchronous I/O for reads (i.e., generation of @@ -172,8 +210,7 @@ .Dq remote side. This command is used by VMware port and expected to be executed on a descriptor, associated with control device -(usually -.Pa /dev/vmnet Ns Sy N ) . +.Pq usually Pa /dev/vmnet Ns Sy N . .El .Pp The control device also supports @@ -199,7 +236,7 @@ and .Nm vmnet devices. VMnet minor numbers begin at -.Va 0x1 +.Va 0x80 + .Va N . Where diff -ru /usr/src/sys/net/if_tap.c ./src/sys/net/if_tap.c --- /usr/src/sys/net/if_tap.c Mon Mar 26 04:41:17 2001 +++ ./src/sys/net/if_tap.c Thu Aug 30 17:51:00 2001 @@ -54,6 +54,9 @@ #include #include #include +#include/* XXX: Shouldn't really be required! */ +#include +#include #include #include @@ -73,7 +76,9 @@ #define TAP"tap" #define VMNET "vmnet" -#define VMNET_DEV_MASK 0x0001 +#define TAPMAXUNIT 0x7fff +#define VMNET_DEV_MASK 0x0080 + /* 0x007f00ff */ /* module */ static int tapmodevent __P((module_t, int, void *)); @@ -111,9 +116,12 @@ /* flags */ 0, }; -static int taprefcnt = 0; /* module ref. counter */ -static int taplastunit = -1; /* max. open unit number */ -static int tapdebug = 0; /* debug flag*/ +static int tapdebug = 0;/* debug flag */ +static SLIST_HEAD(, tap_softc) taphead; /* first device */ +static udev_t tapbasedev = NOUDEV; /* base device */ +
