[Top][All Lists]

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

Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" poi

From: Bernhart Pelger
Subject: Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" pointer.
Date: Wed, 10 Jan 2018 10:26:55 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

Am 08.01.2018 um 20:56 schrieb address@hidden:
Bernhart Pelger wrote:
The Xilinx driver does not use custom_pbufs (as suggested in ZeroCopyRx.c).
Therefore it cannot know when a pbuf is not needed any more.
The Xilinx driver immediately frees the DMA buffer at RX interrupt (yes,
before LWIP has processed it).

I know this sounds fundamentally broken, because other arriving packets
might be overwriting the free'd DMA buffers before LWIP or the
application had a chance to process it.

This does not *sound* fundamentally broken, it *is*!
But that's a different topic, not in the scope of this topic, or even this mailing list.
And it doesn't affect me right now with my usage pattern.

What do you mean by "this (byte-flipping?) can be delayed"?
Do you mean "this (byte-flipping) can cause a delay"?

I meant because of handling out-of-sequence packets at a later point, the
header fields are touched again. Then, they have to be converted again.
And that is a problem because ...?...
Worried about perfromance impact from the conversion operation?
Byte-flipping should be pretty fast (at least compared to memory accessses and conditional statements).

Also, packets arriving in-order is the more likely situation. It's not worth optimizing for that special
case where packets are arriving in wrong order.

Ok, leaving the application programmer more freedom is fine.
But what about the freedom for the driver programmer, to use single
cache-invalidates for some performance gain?

That's what I meant. If someone would make a patch changin TCP to not
write back into the pbuf, I'd probably push it. I just don't want to do
the work ;-)
I might do it at some point, but right now I have no time and
a lack of motivation, since invalidating at tcp_input() works for me
and is fast enough: only one 32-byte cache-line for the tcp header to invalidate.

Regards, Bernhart.

reply via email to

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