|
From: | address@hidden |
Subject: | Re: [lwip-users] PBUF_RAM allocation |
Date: | Thu, 28 Jun 2018 21:23:55 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 28.06.2018 15:10, Amena El Homsi
wrote:
For PBUF_POOL and PBUF_RAM pbufs, pbuf_header() (etc.) will happily add more header room unless p->payload will grow down into struct pbuf. I told you it won't work like you said it would. But you can of course still try if you want.
Wait, you seem to misunderstand this. Pbufs have a payload area and a payload pointer. For PBUF_POOL and PBUF_RAM, the payload area begins right behind the struct pbuf. The payload pointer can point at any point in the payload area. You can never anticipate it by adding some magic counter to the struct pbuf pointer. But you are right that pbuf allocation for UDP wastes some space because room for TCP headers is reserved. This is on my todo list. Also, in dual stack mode, IPv4 has the same problem as room for IPv6 headers is reserved.
No. The short form is: you need to call pbuf_ref() if transmission is *not* synchronously finished before low_level_output() returns. Then you can later call pbuf_free() when you are done with the pbuf. To be on the safe side, you might still need to duplicate the pbuf if PBUF_NEEDS_COPY() returns true (for at least one of the pbufs in a chain). You're working on the oldest open task here (task #7896, "Support zero-copy drivers"), so you're right that this is not working out of the box. However, I'd like that to be supported, but I want to wait with changes until 2.1.0 has been released. Thanks, Simon |
[Prev in Thread] | Current Thread | [Next in Thread] |