On 14 Jul 2008, at 23:50, Garrett D'Amore wrote:

> Joe Kuan wrote:
>> Hi Garrett,
>>
>>   Thank you for the quick response. The reason I need to kernelise
>> the network application as it needs to process 1.3/1.4 millions  
>> packet
>> per second. Do you think using the taskqueue api has any impact on  
>> the
>> performance? In FreeBSD, we are hitting around 80% cpu usage.
>
> If you want to create a single thread, you can do it with a taskq
> function that simply never routines.  Its kind of ugly, but it will
> work.  (It might prevent suspend/resume, though.)

Sorry, can you give me more clue/detail on how to do that? What do you  
mean
by 'can do it with a taskq function that never routines'? Do u mean  
taskq_create? However, I
still need to somehow attach my routine with the thread. Without using  
taskq_dispatch,
how else can I possibly do it?

To give you more information,
my function is simply consumes all the packets inside a queue (if  
there is any) every millisecond.
This function is waken up every ms. In FreeBSD, there are tsleep() and  
wakeup(). I basically stuck
the wakup call inside some clock routine runs every ms.

Many thanks
Joe

>>
>>   Also my function for the network applications takes a mbuf*
>> parameter and processes it. However, if I call ddi_taskq_dispatch for
>> each incoming packet (mbuf), that will require quite a large pool.
>> Will the task pool get exhausted?
>
> You don't have to do that.
>>
>>   Alternatively, should I make the function as an infinite loop
>> instead and pass on to taskq_dispatch only once, then relying on
>> taskq_resume/suspend when packet is ready. Would this be better?
>
> You shouldn't use taskq_suspend/resume.  You don't need to do that.   
> You
> could use your own condvars to signal that.
>
> Actually, you probably want to have a logic that allows for the  
> function
> to run "while there is work to do", and then don't bother to use
> taskq_dispatch if the function can be shown to be "running".  Then if
> function isn't already processing work, you can do taskq_dispatch().
>
>    -- Garrett
>>
>> Many thanks
>> Joe
>>
>> On 14 Jul 2008, at 21:43, Garrett D'Amore wrote:
>>
>>> I'd try first to use a taskq -- ddi_taskq_create(9F) -- they are
>>> documented, and should be stable.
>>>
>>>   -- Garrett
>>>
>>> Joe Kuan wrote:
>>>> Hi all,
>>>>
>>>>   I have managed to kernelised our network application into FreeBSD
>>>> and worked very well. Now, I start the same process on OpenSolaris.
>>>> Although I have got the Solaris Internal book with me, it really
>>>> explains how everything works together. What I need is some  
>>>> tutorial
>>>> or example on how to use kernel functions
>>>>
>>>> On FreeBSD, I can do something like
>>>>
>>>> SYSINIT(foo, ..);
>>>>
>>>> void foo(void *bar) {
>>>>
>>>>  .....
>>>>  kthread_create(my_func, ....);
>>>> }
>>>>
>>>>
>>>> void my_func(void *arg) {
>>>>
>>>>   while (1) {
>>>>
>>>>      do something
>>>>
>>>>      sleep until timeout or wakeup by another signal
>>>>   }
>>>> }
>>>>
>>>> where SYSINIT is to dispatch kernel thread at startup
>>>>
>>>> Here is the link of man page of kthread_create,
>>>> http://www.FreeBSD.org/cgi/man.cgi?query=kthread_create&apropos=0&sektion=0&manpath=FreeBSD+6.3-stable&format=html
>>>>
>>>>
>>>> Here is the link of the info and showing how to use SYSINIT,
>>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/sysinit.html
>>>>
>>>>
>>>> I would be appreciate if anyone can point me to any document/source
>>>> file/man pages/anything on the usage of creating a kernel thread  
>>>> using
>>>> thread_create and also the equivalent mechanism of SYSINIT in
>>>> OpenSolaris.
>>>>
>>>> Many many thanks in advance.
>>>> Joe
>>>> _______________________________________________
>>>> opensolaris-code mailing list
>>>> opensolaris-code@opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>>>>
>>>
>>
>

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to