Tcp ip stack vs. perfo
 

hello all,
I've a question linked to tcp ip stack level and performances.
is it correct to say that the kernel addesses the level 1 to 3 of the ip stack level?
for example when you catch an udp message using a hook in the kernel comparing to open/bind socket and monitor it a Udp level.

I've also read that for performances issues catching a message at kernel level is faster than catching it at udp level. I understand that but how many times faster?

Is it still true as hw items are more powerful and I'm wondering if this gap is still large to avoid doing it?
Thanks for your help

Your terminology isn't very clear to me so maybe explain it with a Real Life problem you're actually trying to solve please?

Hi again,

I've a question linked to TCP/IP stack level and performances. Is it correct to say that the kernel addesses the level 1 to 3 of the TCP/IP stack ?
For example when you catch an udp message using a hook in the kernel comparing to open/bind socket and monitor it a Udp level.

2) Performance issues:
The performance issue deals with the fact to catch a message at Kernel level (https://www.google.fr/url?sa=t&rct=j...2sxXVzqOPzNBsw) comparing with a standard create, open, bind socket and select syscall. http://broux.developpez.com/articles/c/sockets/


I've also read that for performances issues catching a message at kernel level is faster than catching it at UDP level. I understand that but how many times faster? Is it still true as hw items are more powerful and I'm wondering if this gap is still large to avoid doing it?

Thanks for your help

Basically Netfilter is a "hook" into the kernel too, so you define "at UDP level" as using NFQUEUE (which is a hook too) then yes, the latter would be slower because it relays packets through user land?

Pragmatically speaking, it does not matter, and here's why . . .

The process of sending-and-receiving network packets is a physical process, ruled by the physical realities of transmission lines and so-forth, and therefore occurring "on the order of milli-seconds."

The process of interpreting those packets, throughout the various layers of software that do so, takes place at CPU speeds: nano-seconds and micro-seconds. In other words: "at least one, if not two, orders of magnitude time-difference."

Regardless of how many microseconds the CPU spends interpreting each packet as it is sent or received, it simply makes no pragmatic difference to the actual rate at which said packets might be sent or received by the physical(!) hardware.

The software, if it wishes to be, can afford to be as "sloppy" as it wishes to be, and in the end it will make no pragmatic difference at all. The "ruling constraint," in this case, is entirely physical.

Well... it is a little hard to compare an ISO networking model with the TCP networking model as the levels are "mixed up":
http://www.studytonight.com/computer...-osi-tcp-model

TCP only has four layers, not 7. It is also possible (depending on the implementation) that none of the levels are in the kernel (I believe slip is/was implemented nearly entirely in a userspace application for the data link, then there is the "promiscuous mode" of the network interface driver allowing everything). I believe some of the packet layer can also be in user space (https://www.netfilter.org/documentat...g-HOWTO-7.html) for filtering purposes.

About the only time performance comes into play is when dealing with a DoS attack, as it helps to try and catch/drop/block the attacker as soon as possible, but that is usually a user mode activity.