From mboxrd@z Thu Jan  1 00:00:00 1970
From: htmldeveloper@gmail.com (Peter Teoh)
Date: Tue, 10 May 2011 11:14:14 +0800
Subject: Sleep and Wake up
In-Reply-To: <BANLkTimpAEycOnqO1qErguf0zbuLd8yB8g@mail.gmail.com>
References: <BANLkTimpAEycOnqO1qErguf0zbuLd8yB8g@mail.gmail.com>
Message-ID: <BANLkTikesNoX3mvvNYLDrgvu0UKCw7Ng6g@mail.gmail.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On Tue, May 3, 2011 at 2:32 AM, Abu Rasheda <rcpilot2010@gmail.com> wrote:

> I am testing my driver on much faster host processor and facing
> following issues:
>
> My host is too powerful and it can fill up device buffer queue very fast.
>
> I get best performance when I do busy wait, but this is not desirable
> and is bad design.
>
> I need to sleep and wake up quickly and predictability. Indication
> from device that queue has space, is coming in form of memory write
> (device writes to a memory location of i86 processor).
>
> I tried using wait_event_interruptible_timeout, I am depending on 2nd
> parameter of the function but it wake up is too slow, even tried using
> value of 1.
>
> Any suggestions ?
>
>
Many of us are just newbies in this area, and therefore, get it working is
much more important than to optimize it - u can safely said that the
hardcore kernel developer has already optimize many of these problems away,
and so if they cannot do it, there must be a reason...try to probe more
first perhaps.

High speed networking device has many special hardware features: IP/UDP/TCP
checksum offload etc.

http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
http://www.sun.com/products/networking/infiniband/ibhcaPCI-E/docs/datasheet.pdf

Read this about NAPI:

http://www.linuxfoundation.org/collaborate/workgroups/networking/napi

<http://www.linuxfoundation.org/collaborate/workgroups/networking/napi>Eg,
"Interrupt mitigation" - whereby interrupt mechanism is disabled (in
particular my desktop PC's r8196.c is using this feature) and polling takes
over instead - but u have to implemented complicated mechanism to reinject
the interrupt if necessary (read r8196.c).

And if u really ready....this is a good writeup:

http://datatag.web.cern.ch/datatag/howto/tcp.html

Other possible suggestion/features:

Jumbo frames:

http://www.cyberciti.biz/faq/rhel-centos-debian-ubuntu-jumbo-frames-configuration/

PCI posting (pdf paper above and r8196.c).

Disabling TCP software checksum (and use the hardware instead):

http://www.linuxquestions.org/questions/linux-enterprise-47/how-to-disable-tcp-checksumming-690745/

And for loads of other ideas (eg, TCP bypass):

*
http://ttthebear.blogspot.com/2008/07/linux-kernel-bypass-and-performance.html
*

Generally a lot of these ideas can be found in the kernel source codes -
just search and copy the implementation.....the highest network data
transfer is achieved in infiniband-based Mellanox card (in some China
supercomputer), and this involved the use of GPU technology etc....

https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/2009-May/039639.html

-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110510/4263ed73/attachment.html