Re: [lwip-users] udp_send

[Jonathan Larmour]

Julian Gardner [RSD] wrote:
> Thanks for the pointer, looks like udp_send allocates a header 
> pbuf_header( p, UDP_HLEN) at the start but does not remove this when 
> leaving the routine.
>
> Should this be added to the end of the udp_send routine so what you send 
> is what you get back on return? !!!!

We have discussed the issue of whether we should allow pbufs to be reused 
after return. The decision seemed to be that we should allow this. Some of 
the hoops we need to jump through for safe queuing of pbufs could be 
avoided otherwise. This applies to both the payload and the "struct pbuf" 
itself.

So by that token, it implies a pbuf should have its state restored.

But that seems a bit of a faff for something uncommon. Maybe if we do want 
to allow reuse of pbufs, we could insist on a call of an API function, e.g. 
something like:

int pbuf_reuse(struct pbuf *p, pbuf_layer l)
{
  u16_t offset = 0;
  switch (l) {
  case PBUF_TRANSPORT:
   [... same treatment of offset as pbuf_alloc() ... ]
  }
  switch (p->type) {
  case PBUF_POOL:
  case PBUF_RAM:
    p->payload = LWIP_MEM_ALIGN((void *)((u8_t *)p + (SIZEOF_STRUCT_PBUF + 
offset)));
    break;
  case PBUF_ROM:
  case PBUF_REF:
    [do something?]
    break;
}

The only problem here is that pbuf_header allows use of a negative header 
offset for PBUF_ROM and PBUF_REF. If that is done there is no way to 
restore the old value. In fact that's a problem anyway. However although 
the stack uses negative header offset when adjusting _incoming_ pbufs, I 
don't know for definite if it uses negative header offsets for pbufs for 
transmission. I haven't found any examples yet.

I suspect Simon like this approach because it gives a particularly good 
place to check that pbuf->ref is 1 before reuse. On the other hand, it's an 
API change.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine