lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] pbuf handling / possible bug?


From: Michael Steinberg
Subject: Re: [lwip-users] pbuf handling / possible bug?
Date: Wed, 5 Aug 2015 22:57:47 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hi Simon,

many thanks for all these explanations, this is highly apreciated! But
also this makes me feel even more guilty, because I actually forgot to
mention one thing, which turns out to be a showstopper in the route to
diss custom pbufs in favor of this suggested solution. My head is
literally in three places at the same time :(.
Okay, on to the explanation: One of the "services" which are running
here is a Precision-Time-Protocol slave clock. This protocol relies on
hardware time stamping of arrival or transmit of so called "event"
messages. I felt this is so special that it would not be worthwile to
find a way to add timestamping functionality to lwip itself, so I took a
different route. These "event" messages are luckily very small, so I had
the opportunity to bite off memory off the actual receive/transmit
buffers and put kind of "meta" data in there, which includes timestamps
in the rx path or transmit callback pointer in the tx path. This way the
PTP service can communicate directly with the hardware driver, bypassing
lwip, which comes inbetween. And here is actually the really dirty part
of my solution: I use PBUF_REF type to indicate that no meta payload is
hidden behind the buffer and PBUF_RAM to indicate there is meta data
hidden (And of course the custom-flag to differentiate between my own
pbufs and potential lwip pbufs). Now this is really dirty and I need to
find a solution to this... Maybe if some of the flag bits were allocated
for "custom" use in lwip, would that be a solution other people could
live with? I believe this is a great way to support functionality which
just does not really belong to lwip itself, but needs a bit of help from it.

(sidenote: If I'm remembering correctly, this is also the reason why I
could not use the netconn api (other thread), because I needed to be
able to directly send my own pbufs without copying, since the meta data
needs to reach the driver.)

I will see that I get up to date with current git master, thank you for
the pointer!

Kind Regards,
Michael

Am 05.08.2015 um 22:27 schrieb address@hidden:
> Michael Steinberg wrote:
>> I'm using lwip version "1.41 stable" here
>
> Yeah, well, you shouldn't. I know it's bad we don't have a newer
> release but 1.4.1 is really not very "stable" any more: there are a
> *lot* of bugfixes as well as new features in git master that you
> shouldn't miss.
>
> I was always planning to get a 1.5 beta out but haven't found the
> time, yet :-(
> I've just updated the news section on savannah to reflect this.
>
>> I will try to come up with a bug for this. Maybe it is no bug after
>> all because I'm just misusing it, then I'm sorry.
>
> I've already fixed the "line 417" bug. But if you find other
> occurances, please report them to the bugtracker. Sending them here is
> OK for a start but things tend to get lost here as I don't always find
> the time to monitor every mail, especially when bug reports are hidden
> in the third screen after scrolling down the mail on my phone...
>> How can a custom RAM-pbuf possibly reallocate
>
> Well, the "reallocate" (i.e. trim) functionality is not one of the
> features. At least not for now. That one was really a bug. The
> behaviours are more like this:
> - RAM: TX buffer, in one piece, struct pbuf and its payload are
> contiguous memory (although the "in one piece" might be removed in
> future versions)
> - POOL: RX buffer, can be chained (e.g. scater-gather-RX), struct pbuf
> and its payload are contiguous memory
> - REF: can be anything pointing to volatile memory, struct pbuf is
> allocated on its own, payload can be anywhere
> - ROM: same as REF but pointing to non-volatile memory (i.e. when
> queued, payload does not have to be copied)
>
>
> I've just pushed a change trying to document this better in pbuf.h...
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users





reply via email to

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