I am studying how to analyse and evaluate the TCP/IP protocol stack of Linux. My goal is to study the performance of the tcp/ip protocol stack as a whole, to study the time cost of each layer and interaction between the layers of tcp/p protocol and queuinf of the ip layer.
To do the above : I am using a probing node based schema to to study the internal behaviour of TCP/IP protocol of linux. probing node is a piece of code added into the kernel to record the information like timestamp, queuing length and size of packet.
my question : how to add the probing node into the kernel ?
You can use (for example) SystemTap, the main idea behind this tool is to put probing node somewhere: kernel or userspace program.
If you do not have time to learn SystemTap, you can just put some printk in the kernel and read them from dmesg.
In both cases, you are introducing a big delay in the network stack due to the prints. In order to reduce the delay introduced by probing, I suggest you to use SystemTap, store all your time-sample somewhere and print only at the end of acquisition.
Related
Suppose I write some LKM with networking (netfilter) activity and I need to do some tampering with skb including skb_pull(). So I have to take care about is skb linear or not before pulling.
If I generally don't want to have an opportunity to face with non-linear (paged) skb in my system, how can I do this?
In other words: how can I disable producing paged skbs in Linux kernel?
Is there some option on network interfaces to be set up with ethtool or something else?
I think you can refer to the implementation of bpf_skb_pull_data in the kernel, this bpf helper function can pull no-linear data into linear.
https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
I am looking to implement some kind of transmission protocol in C, to use on a custom hardware. I have the ability to send and receive through RF, but I need to rely in some protocol that validates the package integrity sent/received, so I though it would be a good idea to implement some kind of UDP library.
Of course, if there is any way that I can modify the existing implementations for UDP or TCP so it works over my RF device it would be of great help. The only thing that I think it needs to be changed is the way that a single bit is sent, if I could change that on the UDP library (sys/socket.h) it would save me a lot of time.
UDP does not exist in standard C99 or C11.
It is generally part of some Internet Protocol layer. These are very complex software (as soon as you want some performance).
I would suggest to use some existing operating system kernel (e.g. Linux) and to write a network driver (e.g. for the Linux kernel) for your device. Life is too short to write a competitive UDP like layer (that could take you dozens of years).
addenda
Apparently, the mention of UDP in the question is confusing. Per your comments (which should go inside the question) you just want some serial protocol on a small 8 bits PIC 18F4550 microcontroller (32Kbytes ROM + 2Kbytes RAM). Without knowing additional constraints, I would suggest a tiny "textual" like protocol (e.g. in ASCII lines, no more than 128 bytes per line, \n terminated ....) and I would put some simple hex checksum inside it. In the 1980s Hayes modems had such things.
What you should then do is define and document the protocol first (e.g. as BNF syntax of the message lines), then implement it (probably with buffering and finite state automaton techniques). You might invent some message format like e.g. DOFOO?123,456%BE53 followed by a newline, meaning do the command DOFOO with arguments 123 then 456 and hex checksum BE53
My requirement is to store data in kernel..Data are incoming packets from networks..which may be different in size and have to store for example 250ms duration..and there should be 5 such candidate for which kernel level memory management is required..since packets are coming very fast..my approach is to allocate a large memory say 2mb memory for each such candidate..bez kmalloc and kfree have timing overhead..any help regarding that?
sk_buffs are a generic answer that is network related or as Mike points out a kernel memory cache is even more generic answer to your question. However, I believe you may have put a solution before the question.
The bottle neck with LTE/HSDPA/GSM is the driver and how you get data from the device to the CPU. This depends on how hardware is connected. Are you using SPI, UART, SDHC, USB, PCI?
Also, at least with HSDPA, you need a ppp connection. Isn't LTE the same? Ethernet is not the model to use in this case. Typically you need to emulate a high speed tty. Also, n_gsm supplies a network interface; I am not entirely familiar with this interface, but I suspect that this is to support LTE. This is not well documented. Also, there is the Option USB serial driver, if this is the hardware you are using. An example patch using n_gsm to handle LTE; I believe this patch was reworked into the current n_gsm network support.
You need to tell us more about your hardware.
As already noted within the comments:
struct sk_buff, and it is created for that exact specific purpose
see for example http://www.linuxfoundation.org/collaborate/workgroups/networking/skbuff
I wrote a kernel module and used dev_add_pack to get all the incoming packets.
According to given filter rules, if packet matches, I am forwarding it to user space.
When I am loading this kernel module and send udp traffic using sipp,
ksoftirqd process appears and starts consume cpu. (I am testing this by top command)
is there any way to save cpu ?
I guess you use ETH_P_ALL type to register your packet_type structure to protocol stack. And I think your packet_type->func is the bottleneck, which maybe itself consumes lots of cpu, or it break the existing protocol stack model and triggers other existing packet_type functions to consumes cpu. So the only way to save cpu is to optimize you packet_type->func. If your function is too complicated, you should consider to spit the function to several parts, use the simple part as the packet_type->func which runs in ksoftirqd context, while the complicated parts should be put to other kernel thread context(you can create new thread in your kernel module if needed).
I'm writing network application reading packets from UDP sockets and then decrypting them using OpenSSL.
The main function looks like this:
receive(){
while(1){
read(udp_sock);
decrypt_packet();
}
}
Program used to work fine until I added encryption. Now there's a lot of packets lost between kernel buffer and my application (netstat -su - RcvbufErrors: 77123 and growing ;). Packets are rather big (60K) and I try to use it on 1Gbps ethernet (thus problem begins after exceeding 100Mbps)
Sounds normal - decryption taking too much time and packets are coming too fast. The problem is - CPU usage never exceeds 30% both on the sender and the receiver.
Problem disappears after commenting out this statement in decrypt_packet():
AES_ctr128_encrypt();
My question is - is it possible, that OpenSSL is using some set of instruction which are not count in to CPU usage (I use htop and Gnome system monitor)? If not what else can cause such packet loss is CPU power is still available for processing?
How many CPU cores does your system have? Is your code single threaded? It could be maxing out a single core and thus using only 25% of the available CPU.
Using profiler I was able to solve the problem. OpenSSL is using special set of instructions, which are executed in special part of CPU. Shown CPU usage was low, but in fact it was occupied doing encryption, so my application couldn't read system buffer fast enough.
I moved decryption to other thread which solved the problem. And now the thread handling all encryption is shown as using 0% CPU all the time.