RE: [Design] suggestions for parallel processing of input and output packets

RE: [Design] suggestions for parallel processing of input and output packets

[Adam Khan]

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

> 
> Adam Khan wrote:
> 
> > 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
> > and can forward the result via netif_rx. Simarlarly for the
encryption
> > 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
> > 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
> crypto engine (that will send the packet to the other part (either rx
or
> tx)
> - You handle queues your way, to allow for multithread your
encryption.
> 
> 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
> have H/W interrupt.
> 
> 

Re: [Design] suggestions for parallel processing of input and output packets

[Martin Gadbois]

Adam Khan wrote:

> 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?)

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...


>
>
> 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.