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: <goldsi...@gmx.de>
To: "Mailing list for lwIP users" <lwip-users@nongnu.org>
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
> > lwip-users@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> _______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
