From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1EA1442C58 for ; Thu, 8 Jun 2023 07:59:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CD9E40A84; Thu, 8 Jun 2023 07:59:01 +0200 (CEST) Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by mails.dpdk.org (Postfix) with ESMTP id 96FCF40042 for ; Thu, 8 Jun 2023 07:59:00 +0200 (CEST) Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-62606e67c0dso2323936d6.2 for ; Wed, 07 Jun 2023 22:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686203940; x=1688795940; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VYuQQ/3cgXdjhpvYp4efN4dUhwuwgCVsVadxSk1v4B4=; b=nJ7EZK2kIdlYg9cPVecJPUKFFsVdl0t1ADKRe8K371kN5440ZmSR6pqFGpDV2W1Jyt Vs+vAvsjv6iJ+lR8HVy5aR8fMLFFwf5Sj9vHW3MXkGAGYUno5mRAY3NDFiRskSZ7Bb1e LIbtz82Ai2wDye4ZD0DV1QI6/QiP3yG99UWRP53WvbV5kHo976uFbMldxxtd0sXP+HqG MnuMOu7VRQjsi9ycoSFTO0277jRwT1ILKMtM8WsC902u5QpyNEn+F0D7nyD80qZJ08UD 0NyUred7HCelW7gP761gwOgu1AYX6yyy3wNjrtDnuNAUCCPaYv0E9cM50s18lI67hj5I xKhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686203940; x=1688795940; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VYuQQ/3cgXdjhpvYp4efN4dUhwuwgCVsVadxSk1v4B4=; b=che69J4qycAWZhTsTauKSIeHtH7hdqS1HSVNrcBrgQpv66CZAjqceTi61mZ3J1Mzfe LJ5I2AXxqPvNTbjDY/vmKwbZ0XhnkLyN1/euPGe09KozzDcGDDONY/4RKifay2o9XsUl BD/eOu4IhOZC755WYzkTKM7Gk8TvSnCC0alIpzR6eyfwizv20yzz+hJ5hVtmQsqQBX1N 2jeAsRETt7ucQtPUvcaK7Ojzgy0v+kat/3oEHDyzRq6iySOMHR+qbY0Z+LJV0p9vOE+L OcvIpr17iMcTDEgPeN1x5BL7nmIuuq+KKqGnqweKDgV8RtjXIJuGIq8SQVaSnApNijXy rfaA== X-Gm-Message-State: AC+VfDxMYAAsfeu/tBZlRjvcmkr9kDFKaGamqIvJK1v+CQ/hhXwqEZrl DDBk9Cscasg+b2PGSK6p5xJLlTtnL+OezQeW1L6g6FZNFOM= X-Google-Smtp-Source: ACHHUZ45he5mXEa8bt1vzcqP83llaQ6DmmwtxywAFaxuHXK7NLkETgL0T/jeig+hnVTSCNhOlGl8U/9S6rLciHmKqeQ= X-Received: by 2002:a05:6214:766:b0:62b:58af:9a0b with SMTP id f6-20020a056214076600b0062b58af9a0bmr439098qvz.33.1686203939732; Wed, 07 Jun 2023 22:58:59 -0700 (PDT) MIME-Version: 1.0 References: <52e41412-ce40-4407-96ef-13b1a39098a8.luxiang@anweitech.com> In-Reply-To: <52e41412-ce40-4407-96ef-13b1a39098a8.luxiang@anweitech.com> From: Pavel Vazharov Date: Thu, 8 Jun 2023 08:58:47 +0300 Message-ID: Subject: Re: DPDK 22.11 - Question for TCP data processing To: =?UTF-8?B?6Iqm57+U?= Cc: users , =?UTF-8?B?6K645a6d5Lic?= , =?UTF-8?B?6YOR5b2k?= Content-Type: multipart/alternative; boundary="000000000000d8c00c05fd97f284" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000d8c00c05fd97f284 Content-Type: text/plain; charset="UTF-8" > > 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 why you don't want to write your own TCP stack :). Up to my knowledge, available TCP stacks are: - F-stack - it contains the FreeBSD stack from version 13 and it's actively supported. - 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 - 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 - 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 - TCP stack suitable for embedded devices. I don't think it has integration with DPDK though. HTH, Pavel. - --000000000000d8c00c05fd97f284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are not sure that, how can we process those changed TCP packets to de= al 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 proto= col stack, or program a state checking applications in DPDK to calculate TC= P sequence number and cache previous data for possible retransmission by my= self. 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 edg= e cases, etc. The current TCP stacks in the OSes have years of polishing an= d bug fixing in them.
You can check out this article and thread why you don't w= ant to write your own TCP stack :).

Up to my knowledge, a= vailable TCP stacks are:
- F-stack - it contains the FreeBSD stack from version 13 an= d it's actively supported.
- Seastar - they have written their own TCP stack whi= ch can work on top of DPDK. The project is actively developed/supported. Th= ey have told me that their stack is more suitable for CDN scenarios where t= he TCP traffic is a bit more predictable, if I may say it in this way. I me= an, that it's less likely to hit weird edge cases there.
- OpenFastPath - I believe they = have written their own TCP stack which can work on top of DPDK but the proj= ect is not actively supported and the stack is not very well tested with re= al traffic (IMO).
- mT= CP - another TCP stack written from scratch which can work on top of DP= DK. I think this project has not been supported for a long time.
<= div>- lwIP - T= CP stack suitable for embedded devices. I don't think it has integratio= n with DPDK though.

HTH,
Pavel.
-
--000000000000d8c00c05fd97f284--