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