[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Resource starvation

From: Yoav Nissim
Subject: Re: [lwip-users] Resource starvation
Date: Sun, 13 Feb 2011 21:10:00 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

On 13/2/2011 20:38, address@hidden wrote:

> Yoav Nissim wrote:
>> I've opened a ticket for this issue on savannah, and have a few
>> problematic points left.
> Great!
>> 1. Could you give some feedback as to how we should process each of the
>> PCB queues? (e.g retiring a PCB but leaving it to be cleaned up later
>> vs. calling the upper layer with an error such as ERR_ABRT). We're not
>> sure what the correct behaviour should be for each of the PCB
>> types/states.
> I would have thought the code for this is already present in
> netif_set_ipaddr()? I just would have moved this code to a more
> generic function so that it aborts all PCBs which are using the
> netif's IP address as their local address (only if the address is
> changed, listening PCBs can silently be corrected, I guess). Aborting
> these PCBs leads to ERR_ABRT for the upper levels. PCBs using the ANY
> address can live on.
The code in netif_set_ipaddr() does not handle bound PCBs and time_wait
PCBs. The listening PCBs in set_ipaddr() simply have their address
changed, but in our case we need to clean them up.
The active PCBs are taken care of by tcp_abort(). This leaves:
1. time_wait PCBs which I believe can simply be removed.
2. listening PCBs which cannot be processed by tcp_abort() - how do I
clean them up?
3. bound PCBs - I am not sure if I can call tcp_abort() on these, or
whether I would manually call TCP_EVENT_ERR(errf, errf_arg, ERR_ABRT),
and then have them removed. An application may be taken by surprise here...
>> 2. I believe this modification has exposed another problem: We get an
>> ASSERT when our PPP link is disconnected while packets are being
>> actively transferred.
> The old PPP code was really broken regarding multithreading. The
> modifications that were necessary include that *none* of the PPP
> functions may be called from any other thread than the tcpip_thread
> (or the main loop for NO_SYS==1). The single exception here is
> pppInProc(), which can be called from another thread if
> PPP_INPROC_MULTITHREADED==1 (the reason for this is that it would
> otherwise be quite unperformant since we would call into tcpip_thread
> for every byte vs. every packet).
> I'm sorry the change here hasn't been clear, but this is just how lwIP
> works, and the way it was before, it wasn't really thread-safe.
Not a problem. I just need to be sure I understand - this means that all
the functions in ppp.h under the "PUBLIC FUNCTIONS" comment [namely
pppOverSerialOpen, pppClose and pppSigHup] must be called using
> Simon
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

Yoav Nissim
Software Engineer, Software Tools Division
Jungo Software Technologies
Email: address@hidden
Web: http://www.jungo.com
Phone: +972-74-7212138
Fax: +972-74-7212122
Mobile: +972-54-2271315

reply via email to

[Prev in Thread] Current Thread [Next in Thread]