Driver interface related question

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Driver interface related question

shai katzir
Driver interface related question

Hi,

In order to write an interface for my ethernet driver,
I used the ethernetif.c and etharp.c, given in the lwip package.

1. because my driver api function for Send, writes the data immediately to the register, I had to send the Packet in one buffer, and not each pbuf in the chain separately. Therefore, I created in low_level_output a new pbuf which collects the pbufs in the chain into single pbuf chain, and then send to the driver the new pbuf, and release him by pbuf_free.

Can it cause any problem? Can it encounter a separate call for pbuf_free()?

2. After managing to create the driver interface, and to port the lwip into my system by writing sys_arch of my own. It can now communicate with other computers, but
   after running for few seconds, it get stuck in an endless loop, usually in the mbox_fetch of the tcpip_thread, even though the driver keeps on getting packets.

   I made a lot of tests, and in each test it got stuck in a different phase of the program.

   I believe it enters some sort of race condition.
  My main worry is about the interrupt of the driver which handles the receive.
  This Interrupt calls the callback function - 'ethernetif' and pass the data to him. When the Packet enters the function, it gets processed as an IP Packet or an ARP Packet. In both cases, the function uses semaphores (memp sem and pbuf_pool_free sem), which can easily create a block to the program (because those sems are occupied by the application or the tcpip thread) .
Is there a way of handling the input packet without using any semaphores? What is the common implementation for the input callback of the driver?

Can you see any other solution for my problem?

Thanks,

Shai.

 


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Driver interface related question

Frédéric BERNON-2
Driver interface related question
----- Original Message -----
Sent: Wednesday, October 17, 2007 11:43 AM
Subject: [lwip-users] Driver interface related question

Hi,

In order to write an interface for my ethernet driver,
I used the ethernetif.c and etharp.c, given in the lwip package.

1. because my driver api function for Send, writes the data immediately to the register, I had to send the Packet in one buffer, and not each pbuf in the chain separately. Therefore, I created in low_level_output a new pbuf which collects the pbufs in the chain into single pbuf chain, and then send to the driver the new pbuf, and release him by pbuf_free.

Can it cause any problem? Can it encounter a separate call for pbuf_free()?

No, I don't think

2. After managing to create the driver interface, and to port the lwip into my system by writing sys_arch of my own. It can now communicate with other computers, but
   after running for few seconds, it get stuck in an endless loop, usually in the mbox_fetch of the tcpip_thread, even though the driver keeps on getting packets.

   I made a lot of tests, and in each test it got stuck in a different phase of the program.

Most of time, it's a port problem. What lwIP release do you use?

   I believe it enters some sort of race condition.
  My main worry is about the interrupt of the driver which handles the receive.
  This Interrupt calls the callback function - 'ethernetif' and pass the data to him. When the Packet enters the function, it gets processed as an IP Packet or an ARP Packet. In both cases, the function uses semaphores (memp sem and pbuf_pool_free sem), which can easily create a block to the program (because those sems are occupied by the application or the tcpip thread) .
Is there a way of handling the input packet without using any semaphores? What is the common implementation for the input callback of the driver?

Take a look to http://lists.nongnu.org/archive/html/lwip-users/2007-09/msg00097.html, there is some informations from Jonathan about a Zero Copy Ethernet interface. Perhaps it can give you some ideas?

Can you see any other solution for my problem?

Thanks,

Shai.

 


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Re: Driver interface related question

shai katzir
In reply to this post by shai katzir

Hello,

I'm using the 1.2.0 version of lwip without cvs changes.
I ported the package by creating the sys_arch functions as requested, but didn't use the SYS_LIGHTWEIGHT_PROT.  

As i wrote in my previous e-mail, i have a multithread system and i use interrupt for receiveing packets. I read in previous disscussions (bug in PBUF) that it is unsafe to use the pbuf from the interrupt, but i have no choice and i'm trying to get it to work.
after failing to manage without SYS_LIGHTWEIGHT_PROT (the program got stuck quickly) i wrote the sys_protect funcs, and changed the macro to one but it got worse, and kept giving debug messages of "out of memory" on memp "TCP_MSG" and pbufs.

can anyone explain me which method should i use for using this package in a multithreaded system? and how can i use the receiving interrupt to enter a packet to the tcpip mailbox, without blocking the interrupt.

thanks,
shai


Subject: Re: [lwip-users] Driver interface related question
To: "Mailing list for lwIP users" <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Driver interface related question----- Original Message -----
  From: KATZIR SHAY
  To: [hidden email]
  Sent: Wednesday, October 17, 2007 11:43 AM
  Subject: [lwip-users] Driver interface related question


  Hi,

  In order to write an interface for my ethernet driver,
  I used the ethernetif.c and etharp.c, given in the lwip package.

  1. because my driver api function for Send, writes the data immediately to the register, I had to send the Packet in one buffer, and not each pbuf in the chain separately. Therefore, I created in low_level_output a new pbuf which collects the pbufs in the chain into single pbuf chain, and then send to the driver the new pbuf, and release him by pbuf_free.

  Can it cause any problem? Can it encounter a separate call for pbuf_free()?

No, I don't think

  2. After managing to create the driver interface, and to port the lwip into my system by writing sys_arch of my own. It can now communicate with other computers, but
     after running for few seconds, it get stuck in an endless loop, usually in the mbox_fetch of the tcpip_thread, even though the driver keeps on getting packets.

     I made a lot of tests, and in each test it got stuck in a different phase of the program.

Most of time, it's a port problem. What lwIP release do you use?

     I believe it enters some sort of race condition.
    My main worry is about the interrupt of the driver which handles the receive.
    This Interrupt calls the callback function - 'ethernetif' and pass the data to him. When the Packet enters the function, it gets processed as an IP Packet or an ARP Packet. In both cases, the function uses semaphores (memp sem and pbuf_pool_free sem), which can easily create a block to the program (because those sems are occupied by the application or the tcpip thread) .
  Is there a way of handling the input packet without using any semaphores? What is the common implementation for the input callback of the driver?

Take a look to http://lists.nongnu.org/archive/html/lwip-users/2007-09/msg00097.html, there is some informations from Jonathan about a Zero Copy Ethernet interface. Perhaps it can give you some ideas?

  Can you see any other solution for my problem?

  Thanks,

  Shai.




_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users

winmail.dat (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re: Driver interface related question

Taranowski, Thomas (SWCOE)
You want the SYS_LIGHTWEIGHT_PROT defined to 1 for your system.

I'm not sure what method is currently being advocated for posting the
received packet to the mailbox, so I'll defer on that count.  My current
OS is a hard real-time system that allows me to perform blocking actions
(e.g. post to a mailbox, or wait on a semaphore) in interrupt handlers
in a safe way, so I haven't wrestled with that problem, yet.

> -----Original Message-----
> From: lwip-users-bounces+thomas.taranowski=[hidden email]
> [mailto:lwip-users-bounces+thomas.taranowski=[hidden email]]
On

> Behalf Of KATZIR SHAY
> Sent: Friday, October 19, 2007 7:41 AM
> To: [hidden email]
> Subject: RE: Re: Driver interface related question
>
>
> Hello,
>
> I'm using the 1.2.0 version of lwip without cvs changes.
> I ported the package by creating the sys_arch functions as requested,
but
> didn't use the SYS_LIGHTWEIGHT_PROT.
>
> As i wrote in my previous e-mail, i have a multithread system and i
use
> interrupt for receiveing packets. I read in previous disscussions (bug
in
> PBUF) that it is unsafe to use the pbuf from the interrupt, but i have
no
> choice and i'm trying to get it to work.
> after failing to manage without SYS_LIGHTWEIGHT_PROT (the program got
> stuck quickly) i wrote the sys_protect funcs, and changed the macro to
one
> but it got worse, and kept giving debug messages of "out of memory" on
> memp "TCP_MSG" and pbufs.
>
> can anyone explain me which method should i use for using this package
in
> a multithreaded system? and how can i use the receiving interrupt to
enter

> a packet to the tcpip mailbox, without blocking the interrupt.
>
> thanks,
> shai
>
>
> Subject: Re: [lwip-users] Driver interface related question
> To: "Mailing list for lwIP users" <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Driver interface related question----- Original Message -----
>   From: KATZIR SHAY
>   To: [hidden email]
>   Sent: Wednesday, October 17, 2007 11:43 AM
>   Subject: [lwip-users] Driver interface related question
>
>
>   Hi,
>
>   In order to write an interface for my ethernet driver,
>   I used the ethernetif.c and etharp.c, given in the lwip package.
>
>   1. because my driver api function for Send, writes the data
immediately
> to the register, I had to send the Packet in one buffer, and not each
pbuf
> in the chain separately. Therefore, I created in low_level_output a
new
> pbuf which collects the pbufs in the chain into single pbuf chain, and
> then send to the driver the new pbuf, and release him by pbuf_free.
>
>   Can it cause any problem? Can it encounter a separate call for
> pbuf_free()?
>
> No, I don't think
>
>   2. After managing to create the driver interface, and to port the
lwip
> into my system by writing sys_arch of my own. It can now communicate
with
> other computers, but
>      after running for few seconds, it get stuck in an endless loop,
> usually in the mbox_fetch of the tcpip_thread, even though the driver
> keeps on getting packets.
>
>      I made a lot of tests, and in each test it got stuck in a
different
> phase of the program.
>
> Most of time, it's a port problem. What lwIP release do you use?
>
>      I believe it enters some sort of race condition.
>     My main worry is about the interrupt of the driver which handles
the
> receive.
>     This Interrupt calls the callback function - 'ethernetif' and pass
the
> data to him. When the Packet enters the function, it gets processed as
an
> IP Packet or an ARP Packet. In both cases, the function uses
semaphores
> (memp sem and pbuf_pool_free sem), which can easily create a block to
the
> program (because those sems are occupied by the application or the
tcpip
> thread) .
>   Is there a way of handling the input packet without using any
> semaphores? What is the common implementation for the input callback
of
> the driver?
>
> Take a look to http://lists.nongnu.org/archive/html/lwip-users/2007-
> 09/msg00097.html, there is some informations from Jonathan about a
Zero
> Copy Ethernet interface. Perhaps it can give you some ideas?
>
>   Can you see any other solution for my problem?
>
>   Thanks,
>
>   Shai.
>
>


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

AW: Re: Driver interface related question

Goldschmidt Simon
In reply to this post by shai katzir
 
> and how can i use the receiving interrupt to enter a packet to the
> tcpip mailbox, without blocking the interrupt.

With SYS_LIGHTWEIGHT_PROT set to 1, you may allocate a PBUF_POOL from
interrupt context (provided you have a correct implementation for the
SYS_ARCH_PROTECT-like macros!) and the pass this packet to tcpip_input
(should be your netif->input function).

v1.2.0 has some problems with ARP in this context so you might want to
upgrade to something newer (CVS) to receive packets from interrupt
context. But be aware that CVS HEAD has many changes compared to 1.2.0!

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: AW: Re: Driver interface related question

shai katzir
Thanks for all the help, and sorry for nagging but i'm still stuck./

Goldschmidt Simon wrote
 
> and how can i use the receiving interrupt to enter a packet to the
> tcpip mailbox, without blocking the interrupt.

With SYS_LIGHTWEIGHT_PROT set to 1, you may allocate a PBUF_POOL from
interrupt context (provided you have a correct implementation for the
SYS_ARCH_PROTECT-like macros!) and the pass this packet to tcpip_input
(should be your netif->input function).
i used SYS_LIGHTWEIGHT_PROT with 1, and implemented the neccessary functions.
i tried to run a program which receives UDP messages in a loop.
right at start the program got stuck in a loop, saying it cant allocate pbuf.
so i raised the pbufs, then it got stuck by saying there aren't enough memp's( for TCP msg).
so i raised the memps for tcp msgs. then it started to receive some packets and again got stuck,
without pbuf's to allocate. i checked if the alloc and free are working fine( with my sys_prot) and they're
seem to be Okay. the problem is that the program is trying to allocate in a higher rate than the release.

Goldschmidt Simon wrote
v1.2.0 has some problems with ARP in this context so you might want to
upgrade to something newer (CVS) to receive packets from interrupt
context. But be aware that CVS HEAD has many changes compared to 1.2.0!
What kind of problems can be with the arp?
i understand that in my case, all the processing (of the ARP), including the arp reply,
 is done in the interrupt, but can it cause problem?
anyway, my program get stuck when there are no longer any arp messages, so i'm assuming its
not the problem.

Thanks again,
shai


Simon


_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users


Reply | Threaded
Open this post in threaded view
|

Re: Driver interface related question

goldsimon@gmx.de
shai katzir schrieb:

> ...
> so i raised the pbufs, then it got stuck by saying there aren't enough
> memp's( for TCP msg).
> so i raised the memps for tcp msgs. then it started to receive some packets
> and again got stuck,
> without pbuf's to allocate. i checked if the alloc and free are working
> fine( with my sys_prot) and they're
> seem to be Okay. the problem is that the program is trying to allocate in a
> higher rate than the release.
>
>  
You mean memp_malloc() fails in tcpip_input()? That is not a problem, it
only shows packets are coming faster than being processed. In the driver
(ethernetif.c), when tcpip_input() (or netif->input() in this case)
returns an error, the pbuf with the incoming packet has to be freed,
which means a packet is dropped due to system overload. This certainly
isn't solved as good as it might be in the core code since it would be
better to check for available TCP segs before filling a pbuf, but that's
the way it is now...

> Goldschmidt Simon wrote:
>  
>> v1.2.0 has some problems with ARP in this context so you might want to
>> upgrade to something newer (CVS) to receive packets from interrupt
>> context. But be aware that CVS HEAD has many changes compared to 1.2.0!
>>
>>
>>    
>
> What kind of problems can be with the arp?
> i understand that in my case, all the processing (of the ARP), including the
> arp reply,
>  is done in the interrupt, but can it cause problem?
>  
Concurrent access to the ARP table from normal context and interrupt
context which _could_ result in mixing hw addresses.
In your case also concurrent access to the ethernet hardware (when an
ARP request is received which results in sending an ARP response while a
packet is being sent from normal context).
> anyway, my program get stuck when there are no longer any arp messages, so
> i'm assuming its
> not the problem.
>  
I agree it's not the problem here, yes. But nevertheless it is a known
problem in v1.2.0 (which is why 1.3.0 will be released some time in the
far future :).

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users