suggestions for parallel processing of input and output packets
A message that is not in the archive (sent off-list or not yet received): [email protected]
Martin,
Thanks for the info, extremely helpful. I have a couple more questions. The ipsec_tunnel_start_xmit() and ipsec_rcv() routines run as tasklets. In tasklets there is no sleeping or scheduling, From your notes I can use a kernel thread (BTW, a timer routine would sleep - I don't think thats allowed in this context?)
Kernel thread - Is this considered a separate context? Concerns -does the thread sleep - how often is the thread run?
Pointers on with kernel threads and sample code will be appreciated.
Tia,
Adam
Quoted 7 lines
Quoted 4 lines · Adam Khan
It appears that you handle multiple packets using the interrupt generated by the hardware - I don't have an interrupt. My question is if I can for example, in the FS code spawn a kernel thread that has a function that polls for completion of the
decryption
Quoted 1 line
Quoted 1 line
and can forward the result via
netif_rx. Simarlarly for the
encryption
Quoted 2 lines
Quoted 2 lines
process a thread to poll/monitor the hardware and then forward the results via
ip_send. This way I can make multiple processing
requests to
Quoted 6 lines
Quoted 1 line
the hardware.
No problems.
You can emulate H/W easily with software:
- on requests, pass packet to you H/W engine, start a recurring timer
- on timer, check if encryption is done, if so call the callback of
the
Quoted 1 line
crypto engine (that will send the packet to the other part (either rx
or
Quoted 2 lines
tx)
- You handle queues your way, to allow for multithread your
encryption.
Quoted 5 lines
In other words, the hardware interrupts only:
- Get packet from H/W
- Call the callback associated with the request. That can be done with a timer or a kernel thread. There is no
necessity to
Quoted 3 lines
have H/W interrupt.
Quoted 7 lines · Adam Khan
Martin,
Thanks for the info, extremely helpful. I have a couple more questions. The
ipsec_tunnel_start_xmit()andipsec_rcv()routines run as tasklets. In tasklets there is no sleeping or scheduling, From your notes I can use a kernel thread (BTW, a timer routine would sleep - I don't think thats allowed in this context?)
Why would it sleep?
setup_timer(callback_check_hw);
...
void callback_check_hw(...)
{
while (packet available from h/w)
{
take packet;
decide where to send it from packet's context;
if(tx)
ipsec_tunnel_send()
else
ipsec_rcv()
}
}or something like that...
Quoted 5 lines
Kernel thread - Is this considered a separate context? Concerns -does the thread sleep - how often is the thread run?
Pointers on with kernel threads and sample code will be appreciated.
Kernel threads are a normal process, but the processes' memory pages are those of the kernel. No memory context switch required when the kernel schedule those processes. They run as often as any other process with the same priority. Since a kernel thread is a process, it can sleep on events (timer, signals).
But in your situation, I would not use kernel threads - the time it takes to schedule() a process is too much time to wait PER PACKET. Use a timer instead, poll the H/W (or whatever) and if available, call the right function with the completed packet. After all, if you use H/W crypto, you want performance.
for 2.4.x, grep kernel_thread to find example of stock kernel threads. (RTFC)
I also suggest Understanding the Linux Kernel, from O'reilly. A great book on the current topics. (RTFM)
--
==============
Martin Gadbois
S/W Developper
Colubris Networks Inc.