A read() syscall takes longer than a getpid() syscall because read() has more work to do, it actually does a data copy of len bytes, which takes some time (and will be faster/slower if data is cache hot)
What we call the "syscall overhead" is what happens before and after the actual data copy, switching between user and kernel mode.
You make that overhead negligible by calling read() with a large size.
Assuming pv uses splice(), there is one only copy in the workload: copy_from_user() from fixed source buffer to some kernel allocated page, then those pages are spliced to /dev/null.
If the pages are not "recycled" (through LRU scheme for allocation), the destination changes every time and the L2 cache is constantly trashed.
Does the protocol implement any kind of negotiation (ciphers, ...) ? if not, how would you handle future type of attacks against the then hardwired constructions ?
I fully agreed that being in-kernel is the right choice for performance, but the chosen constructs excludes the possibility of using any type of existing crypto hardware accelerator that shines in the IPSEC use-case (cache cold data == no cache flush overhead, fully async processing of packets with DMA chaining). Time to start lobbying SOC vendors :)
> Suppose, for example, that you go to the Bank of America site to transfer some funds or pay a bill. As with Google, and as would happen with any other secure site, it turns out their certificate gets replaced with the Avast certificate. I doubt anyone needs me to lecture them on the potential security issues involved in having a third-party watching their banking transactions without permission!
Antivirus software runs with the highest level of privileges, divert system calls...
They could theoretically log everything you type on the keyboard, no need to MITM SSL connections
> Avast is replacing certificates with its own without bothering to check the validity of those certificates!
It won't help. To serve its purpose, any AQM (active queue management) like fqcodel must be done at the congestion point.
The end-user computer has a faster link than its internet connection upload speed, typically a gig ethernet whereas a xDSL upload speed is a few megabits/s.
If you transfer data to a random website (upload) from the computer, packets will accumulate inside router/modem tx queue, because this is the slowest link between the two hops. This is where it's important to have an AQM running to reorder/drop packets in that queue.
> Each core needs to generate a few thousand data packets per second, because Ethernet packets typically contain up to 1500 bytes. This gives the CPU around 100 microseconds to process each packet.
No it doesn't, not when using TCP Segmentation Offload (TSO)
This only works for a particular use-case: sending static data using TCP, but this is the most common use-case since a typical "video streaming server" is actually a simple HTTP server that serves static MP4/MPEG-TS data.
for each connected client this is what happens
- nginx/apache does sendfile(file, sock, off, <large_number>)
- kernel issue large (> 10kB) DMA read to the file storage backend into a set of memory pages and wait for completion
- kernel allocates/clone a small IP/TCP header (40 bytes)
- kernel gives that small header + set of memory pages to network card, which will segment and create those 1500 bytes packets and send them on wire
if you have a lot of RAM, the read from storage could even be skipped because the previously read data pages are kept in the page-cache with a LRU approach. (help if clients are requesting the same file).
you can easily saturate a 10G link with spare CPU cycles on cheap hardware with that approach, no need to bypass anything.
The L3 layer checksum is useless because IP packet is small and the kernel has to read/write all the fields anyway.
The L4 checksum covers TCP/UDP packet data, which the kernel can avoid touching if necessary.
When a TCP sender uses sendfile(), the kernel does a DMA read from storage to a page if the data is not already in memory (in the so called page cache), and just ask the network card to send this page, prepended with a ETH/IP/TCP header. That only works if the NIC can checksum the TCP packet content and update the header.
If the network card can do TCP segmentation offload, the kernel does not have to repeat this operation for each 1500 bytes packets, it can fetch a large amount of data from disk, and the NIC will split the data in smaller packets by itself.
simple checksum computation and/or verification, indeed most cards can do (sometimes with restrictions: not for IPv6, not for VLAN...)
the other kind of offloading that the kernel can use is TCP Segmentation Offload (TSO), which is much more complex to implement in hardware, and you won't find it on cheap NIC (like Realtek)
The most obvious is that they have multiple cores, and it's easy to completely disable a non functional one.
Now can Intel be more granular than the core level, like running a core with some defect ALU, I really don't know.
What's publicly known from the binning process is that it involves disabling core, reducing total cache size, and finding the maximum working frequency.
The bottom line is that it requires more effort to deal with defects in complex logic, for DRAM they would reduce the total memory size.
Once your hash table and its linked lists have been swapped to disk, each pointer dereference causes a random disk access, which are orders of magnitude slower than RAM.
The problem is that all NAT related issues are not because of NAT itself, but because of the required stateful firewalling for NAT.
To be able to NAT and un-NAT, you first need to classify traffic (that NEW, ESTABLISHED, RELATED,... stuff in Linux netfilter), changing the destination or source ip addresses is only the second part of that process.
Protocols don't break only because of NAT, but mostly because of stateful firewalling, you'll face the same problems with IPv6 if you enable it.
https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77...