Slashdot Mirror


What's New in the FreeBSD Network Stack

jjgm writes "As FreeBSD 5-STABLE approaches, Andre Oppermann has produced a high-level presentation on the changes to the FreeBSD 5.3 network stack. There are many clever tricks for performance and scalability. Amongst other things, Andre claims that FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Linux can't do much more than 100kpps."

28 of 169 comments (clear)

  1. a.k.a. Project Evil by Goyuix · · Score: 4, Interesting

    NDIS Binary Compatibility

    FreeBSD i386 can use binary Ethernet and WLAN network drivers written to the
    Windows XP NDIS 5.1 specification. It is a little cumbersome to convert a NDIS driver
    into a FreeBSD Kernel Loadable Module (KLD): (By: wpaul)

    # ndiscvt -O -i neti557x.inf -s neti557x.sys -n intel0
    # /* Compile and install new kernel with "options NDIS" */
    # kldload intel0

    Man ndis(4), ndisapi(9), ndiscvt(

  2. ?pps by BladeMelbourne · · Score: 2

    All this talk of Mpps and Kpps is making my need to pee more urgent.

    Can someone explain what the 'pps' means? the M and K dont need defining...

    1. Re:?pps by dave_f1m · · Score: 2, Informative

      packets per second

    2. Re:?pps by bohnsack · · Score: 2, Informative

      Pakets per second.

    3. Re:?pps by Shanep · · Score: 4, Informative

      Packets Per Second.

      It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.

      If you had a given amount of sustained data coming into a machine, it would typically be much less taxing if those packets where large, as opposed to the same bandwidth being used up with very small packets.

      Packets are variable length and a single packet will be much larger than a single byte.

      --
      War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
    4. Re:?pps by FooAtWFU · · Score: 3, Informative
      It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.

      Which is what you see in DoSc attacks: stuff like SYN floods and smurf attacks.

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    5. Re:?pps by Shanep · · Score: 4, Informative

      Which is what you see in DoSc attacks:

      Yes. A DoS should be most effective with the smallest packets you can send.

      stuff like SYN floods

      SYN floods work by requestion permision to statefully connect, without then going through with replying to the handshake that is sent back. When done over and over, this eventually fills the table of half-connections, which in turn prevents the initiation of any more connections and thus a denial of service.

      The fact that these packets are small, is coincidental to this discusion. In other words, SYN floods don't work because the packets are small, they work because completing the required handshake sequence is not done.

      and smurf attacks.

      Ahh, DDoS of lots of little packets, via simple spoofing. What fun.

      --
      War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
    6. Re:?pps by Homology · · Score: 4, Interesting
      It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.

      Indeed, in this is very you will see a very marked difference between low and high quality network cards. For instance, the common Realtek NIC offloads alot onto the CPU, and induce many interrupts. While high quality cards, like Intel gigabit, will do much prosessing on the card itself. A "ping -f" while using top can be instructive.

  3. Re:Heh by rtaylor · · Score: 2, Insightful

    I know you're being funny -- but I think the answer most of us would have is "Hopefully not too long".

    If those changes made it into every OS that could use the improvement, then everything networked would find things just that much better without throwing away the old hardware.

    --
    Rod Taylor
  4. Re:pps? by ryanmoffett · · Score: 5, Informative

    Actually, pps (packets per second) is a quite common if not misleading statistic spewed by networking equipment vendors, and has been for years. Packets-per-second doesn't really tell you the characteristics of the packets being sent. One interpretation might be the following:
    The minimum ICMP packet size with Ethernet II encapsulation is 46 bytes. The minimum TCP packet size with Ethernet II encapsulation is 54 bytes. So, 1000000pps of 46 byte ICMP is 368 megabits/sec. And, 1000000pps of 54 byte TCP is 432 megabits/sec. Both of these figures seem realistic to me.

    Now, the maximum length of an Ethernet II packet, regardless of any upper layer protocols is 1514 bytes. 1000000pps of 1514 bytes is 12.1 gigabits/sec. Obviously, that packet size isn't what they were referencing.

    In respect to the link speed, a 1000Mbit or a Gigabit Ethernet link is quite common these days and the above minimum packet size stats aren't out of line.

    Actually, on both OS's with a larger packet size, and thus a lower amount of packets-per-second, a decent machine with 66mhz PCI Gigabit NICs can easily route 500mb/sec through the box.

  5. Re:pps? by Shanep · · Score: 4, Informative

    Packets-per-second doesn't really tell you the characteristics of the packets being sent.

    No it doesn't, however, being capable of sustaining 1 million packets per second, even if they are the smallest packets possible, is pretty impressive.

    The packets have to each be serviced, so at around the same line bandwidth, smallest packets could be coming around 30 times more frequently than the largest packets.

    Lots of small packets tend to be more taxing than much fewer large packets.

    The fact that there is perhaps a 10 fold difference in performance ceiling between Linux and FreeBSD, should show that this is not a simple bandwidth limit. I would go so far as to say that bits per second can be more misleading than packets per second if used alone or in an inappropriate context.

    Packets per second says a lot about the stack, bits per second says more about the interface driver.

    --
    War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
  6. WIll this make it to Mac OS X? by AIXadmin · · Score: 2, Interesting

    The more interesting thing for me is: Will these enhancements make it to Mac OS X?

    As far as I am concerned, the closer Mac OS X under the hood, makes itself closer to FreeBSD the better.

    1. Re:WIll this make it to Mac OS X? by ArbitraryConstant · · Score: 4, Informative

      Unlikely.

      a) While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel. The same tricks might work if they were ported, but that would be more of a rewrite with the same concepts rather than a port.

      b) Who in their right mind uses MacOS X for routing? Serving, fine, but actual network infrastructure? I highly doubt it.

      --
      I rarely criticize things I don't care about.
    2. Re:WIll this make it to Mac OS X? by stab · · Score: 3, Informative

      While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel.

      That's not true. The FreeBSD network stack is used in Darwin with a compat layer. Look at OpenDarwin's cvsweb for an example.

  7. Re:My personal experience with FreeBSD by hugo_pt · · Score: 2, Insightful

    your ignorance is great, pf is already ported to FreeBSD for quite some time as a kernel loadable module, and it will be integrated with 5.3-RELEASE. Have you copy-pasted a FreeBSD flaming text a year old ?

    Please.

  8. Re:pps? by psyconaut · · Score: 2, Insightful

    When even my laptop has 1Gbit networking built-in, I'm not sure how you can say "faster than 100Mbit exists, but it sure isn't common".

    And Mpps is a standard notation for packet forwarding....FYI.

    -psy

  9. Re:pps? by Fweeky · · Score: 4, Informative
    From FreeBSD /usr/src/sys/pci/if_rl.c:
    * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
    * probably the worst PCI ethernet controller ever made, with the possible
    * exception of the FEAST chip made by SMC. The 8139 supports bus-master
    * DMA, but it has a terrible interface that nullifies any performance
    * gains that bus-master DMA usually offers.
    Hopefully RealTek have improved matters with their more recent offerings, especially with the new consumer level GigE chips, one of which I'm using right now...
  10. Re:Sounds great by Anonymous Coward · · Score: 2, Insightful

    You GNU/LNUX zealots with your NIH syndrome. Nothing on earth beats OpenBSD for firewall usage, not even your piece of shit netfilter thing. When it comes to performance FreeBSD and DragonFlyBSD win hands down. But don't worry, you still get the hype.

  11. Re:Sounds great by torstenvl · · Score: 3, Interesting

    The BSD networking stack or some sort of clone thereof is in use on every modern operating system in the world. TCP/IP was originally made on BSD. Try opening ftp.exe on Windows in Notepad. Yep, there it is. Copyright Regents of the University of California. It's everywhere. Even the paradigm of sockets is everywhere. BSD defines networking.

    Also, features lead to bloat, the opposite of "high-performance" so your argument needs further detail to be of any credibility.

  12. We survived a DoS on .edu network by agent+dero · · Score: 3, Interesting

    I read some comments on "it is likely you'll be able to through Mpps at it?"

    YES, it's happened to us, here on our university boxen, somebody got r00ted, and _crackers_ got in through some backdoors on a LOT of machines, then started DoS'ing my department, we have a small P-II 5.2.1 box tossing packets like nobody's business.

    When the college network runs mostly Gigabit, Mpps is a plausible measure of connectivity.

    --
    Error 407 - No creative sig found
  13. That's exactly the point by Santana · · Score: 2, Insightful

    You've got it. Unlike what is perceived from Linux (all software must be free), BSD is about making all software better. That's the benefit of the BSD license that many people (usually GPL fans) don't understand.

    --
    The best way to predict the future is to invent it
    1. Re:That's exactly the point by Anonymous Coward · · Score: 2, Insightful

      Sometimes I'm amazed by Linux developers humbling asking to use my software. "Go right ahead," I tell them, "That's why I put it under the BSD license!" But they still don't get it. While I appreciate the asking, it still find it strange that I get an email about once a quarter asking me to release my BSD licensed work under the GPL so it can be used in GPL projects.

      I guess it's hard for users of a "members only" license to grok the concept of "free for everyone".

    2. Re:That's exactly the point by Brandybuck · · Score: 3, Informative

      Actually you CANNOT relicense BSD code under the GPL. I don't think you understand what "relicense" means. It means to remove the BSD license from the code completely. No Open Source license allows relicensing.

      What you can do, however, is to redistribute BSD licensed code under the GPL. You can also license your own derivative works under the GPL. But you certainly may not take BSD licensed code and file off the license.

      --
      Don't blame me, I didn't vote for either of them!
  14. About FreeBSD and Mac OS X by Anonymous Coward · · Score: 2, Informative

    Sadly it seems that people here are very ignorant about the connection between FreeBSD, and Mac OS X, especially where the Mac OS X kernel is concerned. There are a few people here that are claiming that there is not FreeBSD code in the Darwin kernel, only in the Mac OS X command line apps, and this is blatantly untrue.

    In order to better see just how much FreeBSD code there is in the Darwin/Mac OS X kernel, and how relevant this work in FreeBSD will be to Mac OS X, please read the following links:

    http://www.kernelthread.com/mac/osx/
    http://gobsd.com/code/darwin/xnu/
    http://www.apple.com/ca/macosx/features/darwin/
    http://developer.apple.com/darwin/

    Seriously, with so much documentation available, it's unacceptable for supposedly technical people involved with BSD to not know just how important BSD code is to the kernel of a very nice, and hardly secret or obscure operating system like Mac OS X.

  15. Comment removed by account_deleted · · Score: 3, Informative

    Comment removed based on user account deletion

  16. Re:Just wondering... by Anonymous Coward · · Score: 2, Insightful

    /*
    * Copyright (c) 2003, 2004 Jeffrey M. Hsu. All rights reserved.
    *
    * License terms: all terms for the DragonFly license above plus the following:
    *
    * 4. All advertising materials mentioning features or use of this software
    * must display the following acknowledgement:
    *
    * This product includes software developed by Jeffrey M. Hsu
    * for the DragonFly Project.
    *
    * This requirement may be waived with permission from Jeffrey Hsu.
    * This requirement will sunset and may be removed on July 8 2005,
    * after which the standard DragonFly license (as shown above) will
    * apply.
    */

    http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/s rc /sys/sys/socketops.h?rev=1.5&content-type=text/x-c vsweb-markup
    http://www.google.com/search?q=commi ts+hsu&btnG=Go ogle+Search&domains=leaf.dragonflybsd.org&sitesear ch=leaf.dragonflybsd.org
    http://leaf.dragonflybsd .org/mailarchive/kernel/20 04-07/msg00121.html

    This took a total of 2 minutes to find.

    Why not use google next time before looking like a flaming linux jackass?

  17. Re:Just wondering... by CoolVibe · · Score: 2, Insightful
    This is no different from the constant stream of improvements DFBSD folks appropriate from FreeBSD5, often with no attribution at all.

    Please point out an example where DFBSD doesn't attribute correctly. I think you won't find any. (and if you do, please mail the kernel-list, since the dfbsd crew is very strict about that)

  18. Re:Sounds great by dmiller · · Score: 2

    I suppose you mean getopt_long and not getopt (which IIRC originated in BSD). I suspect that if you use BSD for a while, you may find that you have less need to for the --long-options because the documentation is usually much better on BSD systems (and not suffed into those atrocious info files). If you value terseness or you have to write portable shell scripts, then you probably won't want to use the --long-options anyway.