Joe Kuan wrote:
>
> 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?
Just do taskq_dispatch *once*. The task function can run forever.
>
> 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.
That actually sounds like a poor design, because it won't work with a
tickless kernel, and it kills power savings measures done on some CPUs.
You might want to think about possible alternatives, depending on the
problem you are trying to solve.
-- Garrett
>
> 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
