|
From: | Amena El Homsi |
Subject: | Re: [lwip-users] Packet queuing to an ARP table entry |
Date: | Wed, 15 Nov 2017 15:05:39 +0200 |
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 :-)
and from the Dunkels book " Design and Implementation of the lwIP TCP/IP Stack".
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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
[Prev in Thread] | Current Thread | [Next in Thread] |