[Top][All Lists]
[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 -----
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
>