From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 8DD78A04F0
	for <public@inbox.dpdk.org>; Mon, 13 Jan 2020 08:34:53 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 70C5F1D606;
	Mon, 13 Jan 2020 08:34:47 +0100 (CET)
Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com
 [209.85.222.177]) by dpdk.org (Postfix) with ESMTP id D9CDD1D5EB
 for <users@dpdk.org>; Mon, 13 Jan 2020 08:34:44 +0100 (CET)
Received: by mail-qk1-f177.google.com with SMTP id c17so7635846qkg.7
 for <users@dpdk.org>; Sun, 12 Jan 2020 23:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iith.ac.in; s=google;
 h=mime-version:from:date:message-id:subject:to:cc;
 bh=YoOoY/PSmGNuIYG05vOs9xc5kDldRKTLw/ap5C9kh74=;
 b=HDomn2WPcPRjVQ5Y9a/v37AqpoFD8yYMX8Iq0JLL1Z9mcAKTUNq9Nih+PqRxYk1Ltg
 0ifG6qXcXoz9aaU5Iy/+5eH+RWAVGCVKh65QWKCvdmgtJg/Fza+Hdlt25P190yQmwWj0
 b+BWx7GeAxO28xjSDulrUUJT/6Sq4BjepwJdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
 bh=YoOoY/PSmGNuIYG05vOs9xc5kDldRKTLw/ap5C9kh74=;
 b=pVK442eQ03ZhbM6o0Th6pMR8MTESDL8GQNH6KZBnspqgeay4JSIFmvpNo3RvD6AykW
 zpqS2+Ibhv/TiA/KNOCqbPT4fuOMEQQbxGL/EmsDIm2skl+WWTiGOFyECrXlxoyiYn2/
 Trz6/RpxXI2zvU/fevNiFV+d1yaqIgNYVGLzaqtinExWtZ2ImB7sA+VKU1qQLtunbPss
 T2ML44PjxUnWJTrHD+hXSenhWQIrjPDXcSvXkOo/uBbhs1GfjkegvaVC9hSfECDDzJRr
 6nq/bhUvChX9JjTKtKy15QXsPrkrmyQ2gJ5zwMRDR5opHZXKrzNDVHlbRloolbQ6NGrd
 1dPQ==
X-Gm-Message-State: APjAAAXz6Hvs5EzKHRssUWOs8kIdo9zESPNF1et6XM8EJ+3f8g49d6MN
 1AmKInHbpSrsUxtdMWjLenSyEllMojMa19RYjnx2vtzFs4gtPg==
X-Google-Smtp-Source: APXvYqxZ6WRuspD+9Cb2TAZVWs4clqLg3DySjOIaY81BRCcCOL5IkcoRg5LYtl1F3bBJIKaOpeDrjfD2mMEfuHD+2xA=
X-Received: by 2002:a05:620a:164e:: with SMTP id
 c14mr14197783qko.19.1578900883876; 
 Sun, 12 Jan 2020 23:34:43 -0800 (PST)
MIME-Version: 1.0
From: Suraj R Gupta <surajrgupta@iith.ac.in>
Date: Mon, 13 Jan 2020 13:04:33 +0530
Message-ID: <CAMfGv3=AtM+rqrhVRRH3wfiJskvrcp4ikB+B9S+=UrAq8A2n8A@mail.gmail.com>
To: dev@dpdk.org
Cc: users@dpdk.org
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [dpdk-users] [dpdk-dev] Issue in draining packets when head is null
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org
Sender: "users" <users-bounces@dpdk.org>

Hi all,
This is regarding an issue in the draining packet using rte_reorder_drain.
Suppose we have a window size of 16 and we get packets with sequence no
like 0,1,2,4,5,6. On performing drain operation, I retrieve packets like
0,1,2.
Since now order_buf->entries[order_buf->head] i.e. order_buf->entries[3] is
null i won't be able to any more like 4,5,6. I would be able to do it only
when I get at a packet with a sequence number above window size. This may
be highly undesirable if we have large window sizes say 1024, 2048, etc. we
wouldn't be able to drain any more packets until a packet above window size
is received. Also since the struct rte_rorder_buffer are defined in the
source .c file, we are not able to move head of buffer from applications. *Is
there any specific reasons why it is implemented like this in the library.
Are there any ways to overcome this.*
-- 
Thanks and Regards
Suraj R Gupta