Re: [lwip-users] thread safe issue

[Jonathan Larmour]

Steve Waligurski wrote:
> Jifl,
>
> Unfortunately moving to 1.3.0 is not an easy option with Xilinx, they 
> only just released a port 1.2.0 late last year.  I am using sockets API 
> and my ARP processing is being done with etharp_arp_input() and my IP 
> processing is being done with etharp_ip_input().  It's not completely 
> clear what you want me I do with tcpip_callback(), can you elaborate?

The issue is: what context are you calling 
etharp_arp_input/etharp_ip_input from? And are you calling tcpip_input or 
ip_input directly?

Well, whatever the method you use at present, the only safe way, 
especially for the arp functions, is to do it in the context of the tcpip 
thread. One way to run an arbitrary function in the context of the tcpip 
thread is to use tcpip_callback(). Have a look at src/api/tcpip.c. That's 
not the only way to solve this problem, but I think it's one of the simplest.

Note for efficiency, you can of course process multiple pending packets in 
one callback, rather than the simplistic approach of invoking 
tcpip_callback() for each packet.

In 1.3.0 this is[1] resolved by having a new sort of message to talk to 
the tcpip thread TCPIP_MSG_INPKT, which will call ethernet_input() on 
ethernet interfaces - a new function which handles the 
etharp_arp_input/etharp_ip_input/ip_input calls for you. Currently that 
only works one packet at a time, but I could imagine that changing in 
future for efficiency.

Jifl
[1] Or "will be" strictly since it isn't quite released yet.

> ----- Original Message ----- From: "Jonathan Larmour" 
> <address@hidden>
> To: "Steve Waligurski" <address@hidden>; "Mailing list for lwIP 
> users" <address@hidden>
> Sent: Thursday, January 24, 2008 2:42 PM
> Subject: Re: [lwip-users] thread safe issue
>
>
> > Steve Waligurski wrote:
> >
> > > Hi,
> > >
> > > I'm looking for some advice on an issue I'm seeing in the field with our
> > > new product which is running lwIP 1.10.  Our platform is a Xilinx
> > > Spartan 3E running the Xilinx OS.  The way our unit works is that when
> > > it boots up, it starts issuing UDP packets intended for a server running
> > > our application.  As soon as the server receives one or more of these
> > > packets it makes a TCP connection with the device.  This connection
> > > should stay up indefinitely but it doesn't.   This is usually caused by
> > > a failure to respond to a command which causes the server to drop
> > > the connection.  To make matters worse, randomly our device will not
> > > connect at all and must be power cycled before it will.  Our EMAC core
> > > has been modified to block everything except  our TCP packets and our
> > > ARP requests.  99% of communications starts with  the server sending a
> > > packet and the device responding. In the other 1%, the device sends an
> > > asynchronous packet.  Before doing this I disable the RX interrupt on
> > > the EMAC to avoid any thread issues.  What I don't do though is disable
> > > the RX interrupt when sending out UDP packets after bootup which I do
> > > every 3 seconds.  My question is, will I run into thread issue if the
> > > server tries to make a TCP connection at the exact same time the
> > > device is sending a UDP packet?
> >
> >
> > From what you describe (that there is no protection in the stack when
> > interacting with the EMAC), yes any incoming packets or ARPs would be a
> > problem if so.
> >
> > > Also, what happens if I'm transmitting
> > > a packet and an ARP request comes in?  If I need to stop input packets
> > > during all transmissions, what is your recommendation on how I do this?
> >
> >
> > Upgrade to 1.3.0 ;).
> >
> > Are you using the sequential API or sockets API? If so for 1.1.0 you may
> > want to use tcpip_callback() to invoke your packet processing so it 
> > happens
> > in the context of the tcpip thread. You have to make sure all packets,
> > including the calls to etharp_ip_input() and etharp_arp_input() happen in
> > the tcpip thread.
> >
> > The vital thing is that no lwIP core code can be interrupted by any other
> > lwIP core code.
> >
> > Jifl
> > --
> > eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
> > Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
> > Registered in England and Wales: Reg No 4422071.
> > ------["Si fractum non sit, noli id reficere"]------       Opinions==mine


--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine