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 77D64A0556 for ; Sun, 16 Oct 2022 22:42:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 010BE400D7; Sun, 16 Oct 2022 22:42:43 +0200 (CEST) Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) by mails.dpdk.org (Postfix) with ESMTP id EE24E400D4 for ; Sun, 16 Oct 2022 22:42:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665952960; bh=10b3f8HiyR3tjl4jGWCYHtgw+s3ku/uuhJCveEKs2Es=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=O3ryLDpCRpLGTsOvD+dghNUH2aGE5fS+IlOvH1UlUwDiT0iOaRYMOHh4WvblcmP4vz/A4ly/YsJH9LbgXAAJ4FCadJZBoKUadsDNY5nvDahTHOjjbaTILTo9lEIH22oHN3M8ORIeyCxgO1ftqUzbHAvoiREWUv5KifGkvxZqdKq0iYx8/5GNZPjDbNuwclAMvq3/uanqxNFqvSXk0XtE2x4nPv1m4LElfCxaZ09paZR2gElqkPTBCrZeXh9vvWxP8BDtP4zLCGbiHOD/d3L/I/iecrSDJT9ePQ0MvL+SeO9GDwdTeckFw3qxjs9JzKjkrIQQI7VqpJ/AAzS7THly5w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665952960; bh=1Ic6Gos23exrAjfpMQ1k2IFRCgWeBIk4nJAuyw1sfH2=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=I86ClsxsLtjyNix5xahAKNruYr95WyM7NrEts6luwovGs+QUqvZTBWcSuNm5aPrdtTdrHtN5Qz1HE8Rprf2ELpPFI5vqtLUQ4oPOQOtPg9TMMvweMzSTNFCGyr3sFnMh0bQidFhO72zZkXHJdlnj/rn7rlw00+VToi6TQ/79ik9cWX4P4TWYMbPuFKlDbWozePEaqRpcMgoDAU3M+Anqry988VxwppnIv3hCSw9mAeYjx0ZtdwlJa5MaaL1gLiY+0qYsyeIuYccHMLL2i1nZlerqVBzofHQhXVGgK6OV/qLtSU7akkiZUk5SXmJ2JhAR5Fh8GDrPQ1xWP3Cx8X9WLw== X-YMail-OSG: weQ2kPUVM1lp3THvMLgXjI3UmnmHCA4KJMwm1FHK92WSf34_vtmI.7pb1F5OEEe mWGzjWZvs1J1WOzZRqmUkDSxL8gX9nV2hBbRyl63S9jjHdfUbnO9pi8IA8x6SlwzmcMqK751RJ5M nhDmd4l95J5JYCHCjIDDxNOHgQxSELEbhFoueOb0s4zZGPJytPbjeGQp7CWNYzHRL0cXhi0Hh.kU BPZC6SbT1jjCHwV.8F8slVeRMslpcv3G8N3.8CRDc6hS4A93cOXzFkO8TskNxM6CyOR0EVmLYRbQ .LQL4Tp3uWEZG4bdVEKI4_ScWLfkSwC.w.RteqPr6FqGonuPuBoPNH3UlsMPaxXyxyl8lsCyffvc _4LgDMUJ8FuL2krPNoFMYa4FlWzmEFIoXRfUHvHSErMhh6Ahw8iC58AMq6QV7FtC6JBHIok4_WHw bViaiN6YwXqGI5dK0.YsJXJcuHp__K2P.N_eTNYAssQ2xdeL7Y5FxV53pBEvoYJb7kOcp.zwomiI Ic3abYjiQZO_.aU0VGtLgX04UAsE7I_hWig5DFyKcnnJmZ1OPgEYiU8FF00U.id0kn0Co6qiA12c NfRSRL5q7IEbnAxBlGkjmKxSpAGMZRsnsK12TBQwkYs7a5Y_re8f5dCXiEJiuCMvAM6bI6WLG0OS aliLDzDfwKmfx3h.jfusla.mUqR9xQxOjPyiAOb4z12z2C88go4G6I.nRUC43V6RqKoOIMn.UJSr x9_CF26xcXxia3GvIG4he6u_.q8L9ZeQgrN78r5nBamWGb_MVh8V.MBTTj2Gjh8VErX52jL5SFtW GxP.w6AelgfdtZGSE7RUB_ZdG.EWBeSnGnP7N2r1ERFN2ccobGgL395mBmo6XppSIQpiPXrWGAeu jqtlNwz15ABjPROqyjlkWECa2DY_OwETSF.GY658XEC08nEICThmPMZVE.2M4augDIx2veckiWTb f_shun4fhvgFgXJWRPbXpvg2xJKg8UrqGAdAIJppG9WuxCCeJm6D6_oeALBM35Z2uq_x5fLflyxh zTRrvQsShFzSz3kvV10ygH9Yg3SNc.uK9_.1BPfBIlkG9AUiYAbG5udt7jbwV6JXMdOZIm7pyMqD oPu40olOOouLomz.9KfjxXWbTxn69PzyKouNyyuT_EyqjlLJgsIhREbE8FhouB2SY10rUqxbE1Ui didKbDvfFdn_4xSTGR4OLmcEMrFmTmAHVP88TE3vVoMVD7gxa6c1yOut74Q51Gk9fIqQJr7aOl5r 7DUm7Y0okZZZgh4IDjS.3DGkHpYeQ.Fkp_aBZR7q3nf8UVjaoPXgI0yAHDBT4eOstNBXqz6MfGld u4bN39wz5nbDMH1hhyd4eH2DhyubXgEt5Nk3XV60vgfxMu9HKfYGUgb3DjS182Nyl.wyQIBoU_1q kfzXK.DWqhHtE59Of5Epg1RyBULsSGAaKr99tL9e7dhzyEA5lZO62e4VQze85NHpZunkIL28ZeFu WPOvPZfSk5r_gMFts1OLvJayNJXW.Y8AALkUSqccBwxUbENdaT399BbQAW0kY0NlPgK5UEL6558P cmh9C2VDFcADrLooJpMKvX7J4RCE6XZoKsx7mA6Q84zBvqZxKvawxbFMr45PDij.JM1cwQPeSn8j j3m4bHIvCfBArYBUF3P4PEN.9t6X07zEJm.FVIgVMzBrck8qbmpEWrHER0MVKKQjhdQEyneh5_nl lc1.AjqCgOZtFhWWN1bFdN4n_xNjNffumjV2IlQmnqO_FpCGZ08ZG2tnU1f1bIAqriL_tGCtqNo. MMLrSocr6ykzCWoqzy_SoMHgX2Keh4Zsj3jygSbJ9LeIP0vDQ4JrDmeyIIyBk6QQjpYzUPMrMmTG StT50mzAdVs1zPoL27ijWcl8D7cMG2ynEy9l3_BXuARHAXIwFdYvK9.G9eK1VXWlmOhQXBKzy22O 1PtJGV.MYiU3rbCUIoXBC4Awx_COEIfimdr9kiWhk_2OiM1yvy0e_eq11iS91mUwgMD22ISIp3iJ vOPUZGKLwlJ7V0V2AERqXIgPOPSzZxI9oaxr4LT3Q9aKIGFumAZAdMh1riu21sO.F2kkpzPAiZVv JggwTEdEMXlO0ggEA0i9fkDc8HdQ71ljYvpP6ERVBs3Mk_P69ukpsvq.yUtfAt65VOPco6IwcS.8 wr299gGLRShY5xxQtuT163zDCBZQ6WCMXYpLe7z.TiEQiHXfc0fmEpA.KlcWQPFy2RZURcAXalzW S2XaWvErOOUo- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Sun, 16 Oct 2022 20:42:40 +0000 Date: Sun, 16 Oct 2022 20:42:35 +0000 (UTC) From: R T To: "users@dpdk.org" Message-ID: <1429236180.2587394.1665952955783@mail.yahoo.com> Subject: Reorder buffer question MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2587393_1250253946.1665952955782" References: <1429236180.2587394.1665952955783.ref@mail.yahoo.com> X-Mailer: WebService/1.1.20740 YMailNorrin 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 ------=_Part_2587393_1250253946.1665952955782 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm planning on using the reorder buffer and been running a few tests on it= in a small test program. One scenario is that a few packets are sent to the buffer in order; for exa= mple seq # 1 2 3.then the next batch miss a seq #.=C2=A0 the next batch has= seq # 5 6 7. upon a drain, packets 1, 2, 3 come out but the reorder buffer holds on to 5= 6 7 and they never come out.=20 I think if more packets are sent to the reorder buffer, at some point the s= eq # exceeds the top of the window and packets 5, 6, ... start to come out.= But if no packets are sent, 5, 6, 7 are stuck. Is what I'm seeing the expected behavior? If so, I believe there needs to be a time out feature implemented in the re= order to skip over missing packets in order to keep things moving. Is there a way to get some feedback from folks who implemented this feature= ? ------=_Part_2587393_1250253946.1665952955782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm planning on using the reorder buffer and= been running a few tests on it in a small test program.

= One scenario is that a few packets are sent to the buffer in order; for exa= mple seq # 1 2 3.
then the next= batch miss a seq #.  the next batch has seq # 5 6 7.

upon a drain, packets 1, 2, 3 come out but the reorder buffer holds on to= 5 6 7 and they never come out.

I think if more pack= ets are sent to the reorder buffer, at some point the seq # exceeds the top= of the window and packets 5, 6, ... start to come out.
But if no packets are sent, 5, 6, 7 are stuck.

Is what I'm seeing the expected behavior?

= If so, I believe there needs to be a time out feature implemented in the re= order to skip over missing packets in order to keep things moving.

Is there a way to get some feedback from folks who implemented t= his feature?

------=_Part_2587393_1250253946.1665952955782--