Slashdot Mirror

← Back to Stories (view on slashdot.org)

986MB/s With BSD And Gigabit Ethernet

Posted by Nik on from the free-for-all dept.

WasterDave wrote in with this link to information about zero copy sockets on FreeBSD. Some hunting turned up more detailed information about NetBSD and Gigabit networking. Pointers to similar information for OpenBSD are appreciated...

16 of 34 comments (clear)

  1. Re:Porting to Linux? by Arandir · · Score: 2

    "It's very possible to meet all the criteria of the BSD license, and release a new package under the GPL."

    Copyright law does not allow you to change the copyright of anything that is not yours. Period. Unless the license in question allows you to do this then you simply cannot. It has nothing to do with the license, but everything to do with the law.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  2. Porting to Linux? by decaf_dude · · Score: 2

    Moderators: This is not a flame!
    Excellent job done by FreeBSD developers.
    I'm curious: how difficult would it be to port this feature to Linux? Kernel hacking is not my speciality, but I'd like to hear from someone who's intimate with Linux TCP/IP stack to briefly explain if that would require a major rewrite or could indeed be simply integrated into the existing code.
    After all, you cannot deny it's a rather important feature that speeds up the stack greatly and would improve the performance of the OS, especially when used for routing (any LRP developers in the house?)

    -----
    1. Re:Porting to Linux? by Ingo+Molnar · · Score: 5
      As part of TUX i've implemented zero-copy TCP xmit. It turned out to be a minimal change (barring driver changes), less hassle than we initially thought. Obviously we couldnt have gotten those SPECweb99 numbers without zero-copy TCP xmit.

      One important question is, what MTU have they used. If it's the 9000 byte MTU jumbo gigabit frames then these BSD numbers havent got too practical relevance (i can saturate 8 gigabit cards with TUX, ie. 900MB/sec with 9000 byte MTU). If it's the standard 1500 byte MTU then it's nicer. (hm, i just found it, they indeed used 9000 byte MTU...)

    2. Re:Porting to Linux? by Arandir · · Score: 2

      Besides, the GPL nature of the Linux kernel precludes incorporating BSD code into the 'official' code base.

      It depends upon the nature of the code. If this porting would require slipping in single lines of code here and there, it would be very problematic. However, if the BSD code can be isolated into a single source file, then simply license that file under the BSD and the package as a whole under the GPL. Similar things are done under several GPL projects.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    3. Re:Porting to Linux? by gillham · · Score: 2
      If you have ever read The BSD License then you would know you most certainly cannot remove the BSD license and release the code under the GPL with a "readme" that credits the original BSD licese.

      This would be a copyright violation.

      Looking at the first clause is all that is necessary:

      Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

      1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

      I suppose if you distribute the code via Napster the copyright doesn't matter. :-)

    4. Re:Porting to Linux? by Arandir · · Score: 2

      there is no need to keep the BDS code in a seperate file.

      The BSD license does not allow you to change the license. You certainly can keep the BSD code mingled in with the GPL code, but it is going to be very problematic, which is what I said.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    5. Re:Porting to Linux? by cpeterso · · Score: 2

      As part of TUX i've implemented zero-copy TCP xmit. It turned out to be a minimal change (barring driver changes), less hassle than we initially thought.

      Will your zero-copy TPC xmit be in Linux 2.4? If not, will it be part of the "patched" Red Hat Linux?


      --
      cpeterso
    6. Re:Porting to Linux? by Arandir · · Score: 2

      you can simply add to the copyright statement. this way you can relicense it.

      This would be a major copyright violation. Without the permission to do so, you may not relicense anything. BSD is not public domain.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    7. Re:Porting to Linux? by Arandir · · Score: 2

      "why dyou think BSD lost to AT&T ?"

      A) The BSD license does not allow the license to be changed.

      B) The BSD/AT&T case was settled out of court. No one won. No one lost. AT&T forgave Berkeley's infringment, and Berkeley forgave AT&T's infringement.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
  3. Don't forget... by mosch · · Score: 2

    And of course Drew Gallatin.
    ----------------------------

    1. Re:Don't forget... by Arandir · · Score: 2

      Stupidity should be painful

      It is! The problem is that ignorance numbs :-)

      --
      A Government Is a Body of People, Usually Notably Ungoverned
  4. MB/s != Mbps by scott4000 · · Score: 4

    The units in this case would be in megabits per second, not megabytes per second. 986MB/s would be 7888Mbps, or 7.888Gbps.

    -------
    FreeBSD: The power to serve.

  5. NP? by rockwall · · Score: 2

    nik, why did you use to preface the "from the --- dept." tag line with "NP"?

  6. no, Linux does not have zero-copy sockets by cpeterso · · Score: 4

    From the linux-kernel list:

    David Miller: "make no mistake, for transmit we will at some point have a zero copy scheme available. And you can be certain that when it does happen, the end to end latency will not suffer like it does on other systems for the cases where zero copy makes no sense at all."

    Linus Torvalds: "So don't fall into the trap of thinking that zero-copy is always obviously a win. It isn't."

    Ingo Molnar: "zero-copy makes a RL difference only in a small part of those uses. I very much dislike zero-copy-maniac designs which give up just about everything to get nice bandwith numbers."


    --
    cpeterso
  7. Please provide a reference URL for "turbo sockets" by cpeterso · · Score: 2

    Searching Google for "Linux turbo sockets" or even "turbo sockets" turned up nothing (useful). What are turbo sockets?

    --
    cpeterso
  8. Re:Please provide a reference URL for "turbo socke by edhall · · Score: 3

    The "turbo packet support" feature has just appeared in test versions of pre-2.4 Linux in the past week or two. That's hardly "always had it," as our troll claims (as if a system that isn't even released yet could "have" anything). So it's no further along than the FreeBSD equivalent, and despite the claims of our troll, is just as likely to be a copy of the BSD feature as vice-versa (in other words, unlikely). But of course, the reality is that some other OSes have had zero-copy for quite a long time. So who is copying whom?

    (You'll have to search the "linux-net" list, not the "linux-kernel" list, for a discussion of "turbo packet support" and not "turbo sockets." Not only is our troll such a Linux ignoramous that he doesn't know where to look, he doesn't even know what to call it.)

    It's always a sign of an immature wanna-be when such bare claims of BSD or Linux superiority are made; it's pretty obvious why our troll has decided to remain anonymous. The fact is that Linux and BSD each help make the other better, with friendly competition among the actual developers and a free flow of information between them. With rare exceptions, the attitude between workers in the two camps is one of mutual respect and even occasionally admiration. (Far more dissing goes on within the groups themselves than between them -- it's the camp followers who make all the us-vs-them noises.)

    The Linux vs. BSD lamers simply don't understand what free software development is all about; unlike commercial software, win/win situations are the rule, and not the exception.

    -Ed