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

[leon . woestenberg]

Hello Martin,

> > 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  50<- this number is changed to 50 instead of
the buggy 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.
>
I have thought about this some more. Queued packets on etharp.c do not
affect any layers above etharp.c or some netif.c, so these two layers
are affected anyway. So, the code changes and audit is reduced to the
etharp.c and any Ethernet drivers.

Now, if a driver would support sending multiple packets chained in the
way pictured above, we are done. It requires the least number of changes
and IMHO, is the neatest solution.

Leon.

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