lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Packet queuing to an ARP table entry


From: Simon Goldschmidt
Subject: Re: [lwip-users] Packet queuing to an ARP table entry
Date: Wed, 15 Nov 2017 12:22:34 +0100

Amena El Homsi wrote:
> What I know is PBUF_ROM doesn't mean the actual ROM (stable for very long) 
> but it
> means that the data is immutable and it is located in memory which is not 
> managed
> by the pbuf system. Am I wrong?

Yes, you are wrong. ROM means stable for very long, not const :-)

ROM really means stable for long. E.g. when sending via tcp_write with the 
nocopy flag,
ROM means the data is stable until all retransmissions are done. This can be up 
to some
minutes or hours, depending on the connection. TCP has the sent callback to 
tell the
application when it is done, but ARP does not have this.

As such, when queueing for ARP, we can prevent copying, but you'd never know 
when the
frame has actually been sent.

In this respect, I would be OK with the chang in ARP output, but that won't 
help you much
as your usage of PBUF_ROM seems wrong.

> so I have to add some instructions inside the LwIP code, right?

You can always change lwIP code, but in my opinion, it's always better to work 
together
to get things "mainlined". We'd have to change the queue handling in 
etharp_query()
to change this.

Regarding your original problem: why don't you put (some of) the memp pools 
into the
frame memory?


Simon



reply via email to

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