From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 60C81A04F0;
	Mon, 13 Jan 2020 08:34:46 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id B80541D5EB;
	Mon, 13 Jan 2020 08:34:45 +0100 (CET)
Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com
 [209.85.222.172]) by dpdk.org (Postfix) with ESMTP id D417E1D5E9
 for <dev@dpdk.org>; Mon, 13 Jan 2020 08:34:44 +0100 (CET)
Received: by mail-qk1-f172.google.com with SMTP id x1so7599598qkl.12
 for <dev@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=f7s8kY+OkCNwhwQ3f5pmJOg6XZRyoOh4D7R2nweqk9lmsCPF/2CQF4eGeXcdBfgr4E
 2d2Fp4f1nPvB73TS2EHT4sz8Y8C9J3vvPYHUNRsiIavQ83G05aEjB2bJOK5zdAcHUEBl
 zIR+8+BxVlKuximTFRhR/c5G0aI2AKs9Imo4afFz6u9nZFtOGmjj/U2icOg0WofZl4c8
 0cnpoKL9qTMHIYhjVLytpju3nqT3MEaXLjDgdY/xLJFBGBo1OCijmEJcaGC94+Gke+y3
 Te1E+G3LgNpvypV9vvN1UPSgwPL3N8hYes4wG0gYeCEam2QE3OM6tLajk3HiWNWqRKXd
 s4mg==
X-Gm-Message-State: APjAAAV3fc3XSLhHuTccLp+cVO5lCuJQV+IynBBj+TQcoYMIXrryZcJF
 fulIO8QBdeiX0HFTM53LXO6uRJEh5DGg/lQU1T6VMPA/qW+/LQ==
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-dev] [dpdk-users] Issue in draining packets when head is null
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-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