Re: My planned work on networking stack
On Thu, Mar 04, 2004 at 12:26:51PM -0500, James wrote: J> >that was my thought initially, BUT.. actually... you can J> >actually do this no problem using mrtd dumps and pick it up with a J> >program via bgp device :P no need to create another api it seems :) J> J> errr??? I meant bpf device... Implementing traffic accounting like ip accounting or netflow through a bpf is generally a bad idea, because of poor performance of such a solution. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
Gleb Smirnoff wrote: > > On Thu, Mar 04, 2004 at 12:26:51PM -0500, James wrote: > J> >that was my thought initially, BUT.. actually... you can > J> >actually do this no problem using mrtd dumps and pick it up with a > J> >program via bgp device :P no need to create another api it seems :) > J> > J> errr??? I meant bpf device... > > Implementing traffic accounting like ip accounting or netflow through > a bpf is generally a bad idea, because of poor performance of such a solution. This is not the case. While common wisdom does indeed suggest that BPF is slow it is in fact not the case. We have a netflow-like per AS-number traffic accounting daemon which takes only 2-3% of the CPU on our core routers. We are currently preparing that software package for public release. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
Andre Oppermann wrote: > > > there are still other things freebsd lacks. such as uRPF that > > _SERVICE_PROVIDER_ > > can use. ipfw2 has verrevpath but all it does from what i know is strict > > uRPF > > only. service providers like myself, if we were to use freebsd boxen to > > run our > > network, i am not spending money on a router that doesn't do loose-check > > uRPF. > > this sounds like something linux does too but i refuse to use that :P > > That is pretty easy to implement. I should have it by Friday at latest, > depends on when exactly I find time for it. > > ip verify unicast source reachable-via [any|ifn] > > The ipfw2 command would look like this: ... versrcreach [fxp0] Here you go: http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff This one implements the standard functionality, the definition of an interface through which it has to be reachable is not (yet) supported. Using this option only makes sense when you don't have a default route which naturally always matches. So this is useful for machines acting as routers with a default-free view of the entire Internet as common when running a BGP daemon (Zebra/Quagga or OpenBSD bgpd). One useful way of enabling it globally on a router looks like this: ipfw add deny ip from any to any not versrcreach or for an individual interface only: ipfw add deny ip from any to any not versrcreach recv fxp0 I'd like to get some feedback (and a man page draft) before I commit it to -CURRENT. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sender side Sbuf/Mbuf patch for 5.2.x is ready
The sender side patch for fixing Sbuf/Mbuf can be found at: http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz Patch is for both 4.x and 5.2.x. To apply patch: bzip2 -d < smbuf.patch.tbz | tar -xf - cd net-lion ./restore-src backup# backup files will be modified to ???.org # patch will also backup them to ???.orig # so this is not necessary unless you need to modify them further ./netlion.kp# apply patches For more information about this patch, please refer to: http://dsd.lbl.gov/~jin/network/lion/content.html and http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches Hopefully, we can make this into 5.3-RELEASE. Please test and verify it. Patches are innet-lion/FBSD-$R/mbuf.sb directory. -- Jin Guojun --- v --- [EMAIL PROTECTED] --- Distributed Systems Department http://www.itg.lbl.gov/~jin M/S 50B-2239Ph#:(510) 486-7531 Fax: 486-6363 Lawrence Berkeley National Laboratory, Berkeley, CA 94720 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
"Jin Guojun [DSD]" wrote: > > The sender side patch for fixing Sbuf/Mbuf can be found at: > > http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz > > Patch is for both 4.x and 5.2.x. To apply patch: ... > For more information about this patch, please refer to: > > http://dsd.lbl.gov/~jin/network/lion/content.html > and > http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > Hopefully, we can make this into 5.3-RELEASE. > Please test and verify it. I've just looked through your website and the patch and have a couple of comments. The bottleneck you have identified and measured looks interesting. What I'm missing is a more in-depth description of the problem and what exactly your Lion implementation does. From looking over the patch it seems to include and mix debugging routines, mbuf chain optimizations and references to lion_ functions which are stale. It is not clear what is doing what. If you want this to have any chance of being included you should separate that from each other and provide them in its own patchset preferrably as unified diff (diff -u). You also have to observe the style of the surrounding code more. We have a very strict style guide and patches to existing code must be written in the same way as the surrounding code. Two more things, you are talking about the mtu in your Note file. The MTU is not directly relevant for TCP transfers but the MSS is. The MSS is the maximum payload a TCP segment/packet can transport and is always much lower than the link/path MTU. You have the MSS in the tcpcb.maxseg variable. The other things is that I assume you do file transfers at high speed since an application is probably not capable of producing 1Gbit/s geniue date for transfer. Have you checked out sendfile(2) and tested that with high speed links? The advantage of sendfile is to save the copy from userland to kernel but instead it goes directly from disk-io to mbuf. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
The patch for reducing time traversing queues is good.. I have some questions.. It look sas if you have alos included some parts of files and patches that are for other netLION changes.. what is the status of the other changes.. In particular, the comments mention SACK. Are you developing a robist SACK implimentation for FreeBSD? On Fri, 5 Mar 2004, Jin Guojun [DSD] wrote: > The sender side patch for fixing Sbuf/Mbuf can be found at: > > http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz > > Patch is for both 4.x and 5.2.x. To apply patch: > > bzip2 -d < smbuf.patch.tbz | tar -xf - > cd net-lion > ./restore-src backup# backup files will be modified to ???.org > # patch will also backup them to > ???.orig > # so this is not necessary unless you > need to modify them further > > ./netlion.kp# apply patches > > For more information about this patch, please refer to: > > http://dsd.lbl.gov/~jin/network/lion/content.html > and > http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > Hopefully, we can make this into 5.3-RELEASE. > Please test and verify it. > > Patches are innet-lion/FBSD-$R/mbuf.sb directory. > > -- > Jin Guojun --- v --- [EMAIL PROTECTED] --- > Distributed Systems Department http://www.itg.lbl.gov/~jin > M/S 50B-2239Ph#:(510) 486-7531 Fax: 486-6363 > Lawrence Berkeley National Laboratory, Berkeley, CA 94720 > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
Andre Oppermann wrote: > "Jin Guojun [DSD]" wrote: > > > > The sender side patch for fixing Sbuf/Mbuf can be found at: > > > > http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz > > > > Patch is for both 4.x and 5.2.x. To apply patch: > ... > > For more information about this patch, please refer to: > > > > http://dsd.lbl.gov/~jin/network/lion/content.html > > and > > http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > Hopefully, we can make this into 5.3-RELEASE. > > Please test and verify it. > > I've just looked through your website and the patch and have a couple of > comments. The bottleneck you have identified and measured looks interesting. > What I'm missing is a more in-depth description of the problem and what > exactly your Lion implementation does. From looking over the patch it > seems to include and mix debugging routines, mbuf chain optimizations > and references to lion_ functions which are stale. It is not clear what > is doing what. If you want this to have any chance of being included > you should separate that from each other and provide them in its own > patchset preferrably as unified diff (diff -u). You also have to observe > the style of the surrounding code more. We have a very strict style guide > and patches to existing code must be written in the same way as the > surrounding code. It looks like that you did not read the email closely. Only very short and clear patches are for SBuf/Mbuf in mbuf.sb/ directory. Do not look into other directories which are for LION project, not for TCP. LION is not for TCP/IP. LION is totally different network architecture, but it contains backward compatibility for TCP. That is why there is some code there for this purpose. So, do not be confused. > > Two more things, you are talking about the mtu in your Note file. The > MTU is not directly relevant for TCP transfers but the MSS is. The MSS > is the maximum payload a TCP segment/packet can transport and is always > much lower than the link/path MTU. You have the MSS in the tcpcb.maxseg > variable. The Note is "For future development:" for LION which has nothing to do with TCP. So there is no MSS or tcpcb.maxseg etc. > > The other things is that I assume you do file transfers at high speed > since an application is probably not capable of producing 1Gbit/s geniue > date for transfer. Have you checked out sendfile(2) and tested that with > high speed links? The advantage of sendfile is to save the copy from > userland to kernel but instead it goes directly from disk-io to mbuf. A few things are concerned here. (1) generic I/O for applications. New network architecture has to consider applications that still read//write. (2) computational data may not be on disk but in memory. Scientific programmers may not know mmap. (3) 1 Gbits/s is past. New goal is 100Gbits/s or 1Tbits/s in 200 ms RTT, and wireless networks. -Jin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
The Network LION (aka LION, Net-Lion) is a totally different network architecture that we proposed to replace TCP/IP. It has compatibility to TCP/IP for current stage. Backward compatibility is important to it can be deployed without forcing every one do at the same time, which is impossible to do. The goal is to move L3 on board, and leave L4 in system, so we can use PC to drive NICs as fast as possible. LION has been tested cross some Internet paths, and will be tested over emulation lab. Over emulation network (10 Gb/s), we can manipulate different network situations in order to verify Lion will fit in future network without causing network collapse. I hope that Lion will be soon ready for generic test, that is why I put all TCP/LION API code in FBSD-5/netlion directory, which is not part of the standard TCP patch for fixing SockBuf and Mbuf issues (someone was confused by this -- It is not in FBSD-4/ directory). This is for people who may be interested in using Lion. People may take look the code in advance to understand what these patches do because Lion will be provide as a kernel loadable module till it is matured. This means Lion is BSD only at this moment. In LION architecture, all lost packets will be reported to sender via some mechanism. In TCP backward compatible code (called TCP Lion -- not Network Lion), a better SACK will be implemented. Also notice that TCP Lion can be sender modification only. That is, remote site may run Linux/Solaris/Any TCP. Lion architecture must accommodate such case and be robust. -Jin Julian Elischer wrote: > The patch for reducing time traversing queues is good.. > I have some questions.. > > It look sas if you have alos included some parts of files and patches > that are for other netLION changes.. what is the status of the other > changes.. In particular, the comments mention SACK. Are you developing a > robist SACK implimentation for FreeBSD? > > On Fri, 5 Mar 2004, Jin Guojun [DSD] wrote: > > > The sender side patch for fixing Sbuf/Mbuf can be found at: > > > > http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz > > > > Patch is for both 4.x and 5.2.x. To apply patch: > > > > bzip2 -d < smbuf.patch.tbz | tar -xf - > > cd net-lion > > ./restore-src backup# backup files will be modified to ???.org > > # patch will also backup them to > > ???.orig > > # so this is not necessary unless you > > need to modify them further > > > > ./netlion.kp# apply patches > > > > For more information about this patch, please refer to: > > > > http://dsd.lbl.gov/~jin/network/lion/content.html > > and > > http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > Hopefully, we can make this into 5.3-RELEASE. > > Please test and verify it. > > > > Patches are innet-lion/FBSD-$R/mbuf.sb directory. > > > > -- > > Jin Guojun --- v --- [EMAIL PROTECTED] --- > > Distributed Systems Department http://www.itg.lbl.gov/~jin > > M/S 50B-2239Ph#:(510) 486-7531 Fax: 486-6363 > > Lawrence Berkeley National Laboratory, Berkeley, CA 94720 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Please confirm your HotPOP Forwarding Address
DO NOT REPLY TO THIS MESSAGE Someone (hopefully you) has recently requested that all mail sent to [EMAIL PROTECTED] be forwarded to this address ([EMAIL PROTECTED]). If you wish to authorize this, please click on the link below, or copy and paste it into your web browser. http://www.hotpop.com/[EMAIL PROTECTED]&[EMAIL PROTECTED]&AUTH=S9V5B7X5P1M5N9B6 If the link above does not work, you can also authorize this address by typing the following code into the "Mail Forwarding" page in your HotPOP account setup page. Authorization Code: S9V5B7X5P1M5N9B6 No mail will be forwarded until authorization is complete. If you do not wish to authorize this, please ignore this message. Thank you, The HotPOP Team ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
