Hi Simon,
On Fri, Apr 11, 2014 at 07:45:25PM +0200, Simon Goldschmidt wrote: > Sylvain Rochet wrote: > > I put the PPP header into the allocated space for PBUF_LINK if there is > > enough space to do so, for a 14 byte PBUF_LINK_HEADER this is 12 bytes > > of RAM wasted for NO_SYS=1, and 8 bytes for NO_SYS=0 with 32 bits > > pointers, for me this is an acceptable outcome. > > Yes, you're right. The patch also looks good. Although I can't really > test it myself... I slightly improved it, we only allocate a PBUF_LINK if IP forwarding is enabled, so we are not wasting RAM for rx-only devices. > What about other sources of pbuf allocation? I think there are now > more than in the 'old' ppp code. All other allocation in PPP (except VJ) is for output buffers, we only care about input buffers for IP forwarding, and more specifically, we only care about IP and IPv6 PPP packets, all others PPP packets (LCP, IPCP, IP6CP, PAP, CHAP, EAP, …) are obviously out of the IP forwarding scope. > Are there more allocations we need to take care of (e.g. VJ > decompression)? Yup, VJ support required some work because it prepends a pbuf to realign the buffer, I hope it works :-) > BTW: what do you think about making ppp_new the default for 1.5.0? That would be great. I am currently using it in production for some time and it works nicely, at least for me ;-), with PPPoL2TP (VPN link) over PPPoE (ADSL Modem) and over PPPoS (GPRS Modem). > Can it handle IPv6 correctly or are there additions needed? It can, but, well, PPP IP6CP is somewhat limited, it only negotiate a random link-local address for each side, maybe IPv6 ”autoip” works over a PPP link, I just don't know :) So, it works, at least, the PPP simple job for IPv6 works: ppp_link_status_cb: PPPERR_NONE … our6_ipaddr = FE80::1C66:89CD:2A6B:FEA3 his6_ipaddr = FE80::9C58:704B:C4A6:8542 $ ping6 -I ppp0 FE80::1C66:89CD:2A6B:FEA3 PING FE80::1C66:89CD:2A6B:FEA3(fe80::1c66:89cd:2a6b:fea3) from fe80::9c58:704b:c4a6:8542 ppp0: 56 data bytes 64 bytes from fe80::1c66:89cd:2a6b:fea3: icmp_seq=1 ttl=255 time=0.278 ms 64 bytes from fe80::1c66:89cd:2a6b:fea3: icmp_seq=2 ttl=255 time=0.309 ms > I think it might be bigger than the old code, but also more buggy. And > it's kind of meaningless keeping the old code when everyone starting > with a PPP device takes the ppp_new branch... Yup, it is bigger in code size, but not that much, however it uses less memory (about 3 or 4 times less per PPP session IIRC), mainly due to static tx buffer removal and cleaned structs. > Having upgrading instructions for applications using the 'old' pop > code would be nice, of course. I fully agree, will do. Sylvain
signature.asc
Description: Digital signature
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users