It's not rocket science to "bypass the network stack". At worst it's the same, without the extra plumbing. Your getting packets at interrupt time as soon as their processed and you there's no network stack involved, and your able to receive and transmit without a process switch. > It's not faster than "wedging" into the if_input()s.
> On May 4, 2015, at 10:29 AM, Barney Cordoba via freebsd-net wrote: This completely flies in the face of RFC 4835. Why, in 2015, does anyone think it’s acceptable that the setkey(8) man page documents, of all things, DES-CBC and HMAC-MD5 for a SA? That’s some kind of sick joke, right? Why, in 2015, does anyone think it’s acceptable for “fast forwarding” to break IPSEC? Why, in 2015, does FreeBSD not ship with IPSEC enabled in GENERIC? (Reason: each and every time this has come up in recent memory, someone has pointed out that it impacts performance. Why, in 2015 does the kernel have a ‘fast forwarding’ option, and worse, one that isn’t enabled by default? Shouldn’t “fast forwarding" be the default? This is exactly the point at which the adoption curve for 1Gbps Ethernet ramped over a decade ago. Broadwell-DE (Xeon-D) has 10G in the SoC, and others are coming.ġ0Gbps switches can be had at around $100/port. ġ0Gbps NICs are $200-$300 today, and they’ll be included on the motherboard during the next hardware refresh. Monitoring systems and traffic generators, however, must be able to deal with worst case conditions.”įorwarding and filtering must also be able to deal with worst case, and nobody does well with kernel-based networking here. The use of large frames reduces the pps rate by a factor of 20.50, which is great on end hosts only concerned in bulk data transfer. This translates to about 200 clock cycles even for the faster CPUs, and might be a challenge considering the per- packet overheads normally involved by general-purpose operating systems. How- ever a 10Gbit/s link can generate up to 14.88 million Packets Per Second (pps), which means that the system must be able to process one packet every 67.2 ns. Taking as a reference a 10 Gbit/s link, the raw throughput is well below the memory bandwidth of modern systems (between 6 and 8 GBytes/s for CPU to memory, up to 5 GBytes/s on PCI-Express x16). Here are two threads which are three years old, with the issues it points out still unresolved, and multiple places where 100ns or more is lost:ġ00ns is death at 10Gbps with min-sized packets. There is a lot of kernel infrastructure that is just plain crusty(*) and which directly impedes performance in this area.īut there is plenty of cruft, Barney. It works, but it doesn’t work well, because of other infrastructure issues.īoth of your statements reduce to the age-old, “proof is left as an exercise for the student”.
In a similar way, “You can just pop it into any kernel and it works.” is also not helpful. While it is a true statement that, "You can do anything in the kernel that you can do in user space.”, it is not a helpful statement.
0 kommentar(er)
