RE: Fast HDLC driver

RE: Fast HDLC driver

[Joakim Tjernlund]

Hi Owen

I have written a patch to 8xx_io/enet.c that avoids copying. It still calls
netif_rx from IRQ context, but it's a start. The patch was posted a few weeks
ago to this list.

Could you post a copy of the qslinux hdlc driver? I am interested to se how
one would avoid calling netif_rx from IRQ context.

      Jocke
>
>
> Hi all,
>
> I`ve started working on a new project were a high
> performace hdlc channel is needed (at least 4Mbps on
> MPC8xx-50Mhz).
> I found several drivers for hdlc, but some are not
> very fast (copies memory,... ), most of them calls
> netif_rx from inside interrupt_handler (I don`t think
> this is the best place for doing that, watchdog may
> expire if the interface gets very busy..).
> The only driver I found that seems to be really fast
> and doesnt do all this stuff in interrupt context is
> for kernel-2.2 (QSLINUX).
> Does anyone ported this to 2.4 or knows another
> implementation of hdlc driver that could do this the
> way I`m thinking?
>
> Thanks in advance, Owen.
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

memory management bug??

[Owen Green]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

Hi all,

I was making some tests in my linux box and I just
realized that when the system goes to a "low memory
state" kswapd gets almost all the cpu, I've got this
from top (see attached file). But the worst I guess is
that I can't see to where my memory has gone, top
output and /proc/meminfo seems to be "hidding" some
...
I'm using kernel 2.4.4 from Denx, is there memory leak
in this kernel version? How can I reduce kswapd cpu
usage?

Thanks in advance,

Owen.

[-- Attachment #2: memory_problems_output.txt --]
[-- Type: text/plain, Size: 1305 bytes --]

 12:34am  up 34 min,  0 users,  load average: 1.37, 1.33, 0.89
9 processes: 7 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:   7.2% user,  92.8% system,   0.0% nice,   0.0% idle
Mem:     14712K total,    13696K used,     1016K free,     6144K buffers
Swap:        0K total,        0K used,        0K free,     4812K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
    3 root      16   0     0    0     0 RW   78.4  0.0  12:20 kswapd
  150 root      18   0   420  428   120 R    18.9  2.8   0:19 top
    5 root       9   0     0    0     0 SW    2.9  0.0   0:28 bdflush
    1 root       8   0   144  144     0 S     0.0  0.9   0:26 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:00 keventd
    4 root       9   0     0    0     0 SW    0.0  0.0   0:00 kreclaimd
    6 root       9   0     0    0     0 SW    0.0  0.0   0:01 kupdated
   21 root       9   0   212  212     0 S     0.0  1.4   0:11 sh
  106 root       9   0   224  224     0 S     0.0  1.5   0:00 xinetd

# ps
  PID  Uid     Stat Command
    1 root     S    init
    2 root     S    [keventd]
    3 root     R    [kswapd]
    4 root     S    [kreclaimd]
    5 root     S    [bdflush]
    6 root     S    [kupdated]
   21 root     S    -sh
  106 root     S    xinetd
  151 root     R    ps
#

Re: Fast HDLC driver

[Roland Dreier]

>>>>> "Owen" == Owen Green <owenjinggreen@yahoo.com> writes:

    Owen> most of them calls netif_rx from inside interrupt_handler (I
    Owen> don`t think this is the best place for doing that, watchdog
    Owen> may expire if the interface gets very busy..)

I don't have a specific answer about HDLC, but I think calling
netif_rx() from interrupt context is correct.  netif_rx() doesn't do
anything except queue the packet for processing and then mark the
network softirq.  In fact if you want to call netif_rx() from
non-interrupt context then you have to use the netif_rx_ni() function
to make sure the softirq runs soon enough.

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Fast HDLC driver

[Roland Dreier]

>>>>> "Ricardo" == Ricardo Scop <scop@digitel.com.br> writes:

    Roland> I don't have a specific answer about HDLC, but I think
    Roland> calling netif_rx() from interrupt context is correct.
    Roland> netif_rx() doesn't do anything except queue the packet for
    Roland> processing and then mark the network softirq.  In fact if
    Roland> you want to call netif_rx() from non-interrupt context
    Roland> then you have to use the netif_rx_ni() function to make
    Roland> sure the softirq runs soon enough.

    Ricardo> Hmm, is this true? QSLinux driver calls netif_rx() from
    Ricardo> thew interrupts bottom half; it it ok?

This should probably be OK.  First, a bottom half is still interrupt
context.  Second, if I recall correctly, Linux 2.2 does not even
define netif_rx_ni().  If the driver works well there's no reason to
change it.

Best,
  Roland


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/