>
> We are not sure that, how can we process those changed TCP packets to deal
> with various retransmissions like out-of-order, packet loss and so on. I am
> also review the previous threads in this mailing list. But as a newbie, I
> am not sure if I should turn to F-stack, KNI for the help from the protocol
> stack, or program a state checking applications in DPDK to calculate TCP
> sequence number and cache previous data for possible retransmission by
> myself. Or you may have better solution suggestions for us.
>
Hi,

I'd suggest not trying to handle the TCP protocol by yourselves. It's error
prone, full with edge cases, etc. The current TCP stacks in the OSes have
years of polishing and bug fixing in them.
You can check out this article and thread
<https://news.ycombinator.com/item?id=12021195> why you don't want to write
your own TCP stack :).

Up to my knowledge, available TCP stacks are:
- F-stack <https://github.com/F-Stack/f-stack> - it contains the FreeBSD
stack from version 13 and it's actively supported.
- Seastar <https://github.com/scylladb/seastar> - they have written their
own TCP stack which can work on top of DPDK. The project is actively
developed/supported. They have told me that their stack is more suitable
for CDN scenarios where the TCP traffic is a bit more predictable, if I may
say it in this way. I mean, that it's less likely to hit weird edge cases
there.
- OpenFastPath <https://github.com/OpenFastPath/ofp> - I believe they have
written their own TCP stack which can work on top of DPDK but the project
is not actively supported and the stack is not very well tested with real
traffic (IMO).
- mTCP <https://shader.kaist.edu/mtcp/> - another TCP stack written from
scratch which can work on top of DPDK. I think this project has not been
supported for a long time.
- lwIP <https://www.nongnu.org/lwip/2_1_x/index.html> - TCP stack suitable
for embedded devices. I don't think it has integration with DPDK though.

HTH,
Pavel.
-