lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Relationship between lwIP options


From: Alexandre Malo
Subject: Re: [lwip-users] Relationship between lwIP options
Date: Mon, 3 Aug 2009 16:36:43 -0400

If you say PBUF pool is only for incoming packet, then lwip SNMP driver is in Fault.
 
SNMP uses pbuf to send trap and response:
 
err_t
snmp_send_response(struct snmp_msg_pstat *m_stat)
{
...
/* try allocating pbuf(s) for complete response */
  p = pbuf_alloc(PBUF_TRANSPORT, tot_len, PBUF_POOL);
 
...
 
  pbuf_free(p);
  LWIP_DEBUGF(SNMP_MSG_DEBUG, ("snmp_snd_response() done\n"));
  return err;
}
 
err_t
snmp_send_trap(s8_t generic_trap, struct snmp_obj_id *eoid, s32_t specific_trap)
{
...
 
/* allocate pbuf(s) */
      p = pbuf_alloc(PBUF_TRANSPORT, tot_len, PBUF_POOL);
...
 
/** connect to the TRAP destination */
   udp_connect(trap_msg.pcb, &trap_msg.dip, SNMP_TRAP_PORT);
   udp_send(trap_msg.pcb, p);
   /** disassociate remote address and port with this pcb */
   udp_disconnect(trap_msg.pcb);
 
   pbuf_free(p);
 
...
}
 
Alex
 
----- Original Message -----
From: <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Monday, August 03, 2009 1:37 PM
Subject: Re: [lwip-users] Relationship between lwIP options

> JM schrieb:
> > I'm trying to understand all these options in opt.h/lwipopt.h so I can
> > assign them intelligently instead of guessing and wondering why
> > communication fails.  So, this is what I think is correct; please
> > correct me if I'm wrong:
> >
> > In the case of all PBUFs being the same size as defined by
> > PBUF_POOL_BUFSIZE:
> >
> > -There is no point in making MEMP_NUM_TCP_SEG  > PBUF_POOL_SIZE since
> > each segment must use one PBUF at minimum, and actually can cause
> > dropped packets since there will be no space for incoming packets
> > despite MEMP_NUM_TCP_SEG not hitting its limit.
> >
>
> These two (tcp segments and the pbuf pool) are not really related to
> each other: segments are used for outgoing packets only (in conjunction
> with RAM- or REF-pbufs), while the pbuf pool is only used for incoming
> packets. The only exception for that rule is that segments are also used
> for out-of-order segments on the RX side, but that's another issue...
>
> >
> > -(TCP_SND_BUF / PBUF_POOL_BUFSIZE) is the effective limit on the
> > number of outgoing segments in the queue, so TCP_SND_QUEUELEN might as
> > well be set equal to this limit, at least in the case of very small
> > outgoing packets that fit into one PBUF.
> >
>
> Totally not: as I already wrote above, the pbuf pool is used for RX
> packets only! For each call to tcp_write(), one or more PBUF_RAM pbufs
> are enqueued (if copying data; if not copying, PBUF_REF is allocated) in
> a segment. Multilpe pbufs are then enqueued for one segment until that
> segment reaches the maximum segment size, at which point a new segment
> is allocated and pbufs are in turn enqueued to it. Thus TCP_SND_BUF
> (number of outgoing unacked bytes) can not berelated to the number of
> pbufs used for these bytes.
>
> This allocation strategy is not the optimum we can get, which is why we
> started a one-pbuf-per-segment approach, which is, however, not yet
> included in CVS or v1.3.1.
>
> Simon
>
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > lwip-users mailing list
> >
address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
> _______________________________________________
> lwip-users mailing list
>
address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
reply via email to

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