lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] Memory leak and queued packets in etharp.c


From: Martin . Glunz
Subject: [lwip-users] Re: [lwip] Memory leak and queued packets in etharp.c
Date: Thu, 09 Jan 2003 01:56:56 -0000

I'll send this again, because the first time I used
a bad email address that might be rejected by the list.
Sorry if you should receive this message twice.

Quoting address@hidden:

> 
> Hello Martin and others,
> 
> > address@hidden wrote:
> > >
> 
> >As I wrote as a comment, I think that no packets
> >should be dropped (at least not UDP). We'll need
> >some kind of a chained queue (or simply an array)
> >for the packets to be resent. Perhaps I'll do
> >this within the next one or two weeks.
> >
> My proposal was to use the ->next pointer in combination
> with the tot_len field.
> 
> See this chained list of 2 packets, consisting of
> 4 resp. 2 pbufs.
> 
>         #1 #2 #3 #4  #5  #6
> tot_len 80 60 40 20 100 100
> len     20 20 20 20  50  50
> 

Interesting Idea. Should work without adding additional fields
to the pbufs. But as you said:

> However, this would change the ways pbuf's are linked and
> thus introduce changes for the complete stack, or at least
> needs a code-audit to ensure that this use of the pbuf
> structure does not affect current code.
> 
> In am interested to hear about how you would implement
> queueing more than just 1 pbuf.
> 

My very first thougt was something like your proposal, but
with an additional flag inside the pbuf struct. But I didn't like
this idea, because it would heavily change the established structures.

At the moment my idea is to encapsulate the whole queuing and
resending inside etharp.c. An array of 3..5 pbuf * or
a chained list of pbuf * is added to the arp entries. When an
ARP reply is received, the resending is handled inside 
etharp_input(). The only drawback is that etharp_input() must
be able to call the netif lowlevel output function. I guess,
somehow a function pointer must be passed to etharp_input().

This should keep changes down to the netif Modules and
would also obsolete the etharp_output_sent(p) fix.

Martin Glunz

[This message was sent through the lwip discussion list.]




reply via email to

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