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 EEF1AA0A0C for ; Sun, 13 Jun 2021 14:53:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D43724003F; Sun, 13 Jun 2021 14:53:34 +0200 (CEST) Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by mails.dpdk.org (Postfix) with ESMTP id 263A74003E for ; Sun, 13 Jun 2021 14:53:33 +0200 (CEST) Received: by mail-ed1-f42.google.com with SMTP id dj8so42839446edb.6 for ; Sun, 13 Jun 2021 05:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eHTIunh7i80u0ho1Yj2oV0/P2fSS5tsNwMZcJYurt1w=; b=LXzn5XnAxw5OAXHkjRiSEM0t4ylXa1/H0MB3/6CwEceeTaKOqMRsb7j4d4HaI0BxNq tQQNSvmjT11ZCEAAyyj4IvCv1f8tTc5R+RUcRBr/2fEZiShJDM6rjM+naRVa/qWHStI0 wgqldb4TZqevuhnzdmEiaPkGoDL/gBPglOza/4ho+Mh/fgyfpOpFGYZ8XbYhVaQQiGjQ 1vnDRbfdt3J7+ENz8zK9tILjGg0q2bIDyG/8kdkBaXKVQpgs6T7sae9T4DjcCXiXAZJY v/W4CFwi2GEbgH1OEy4X/eO1VII4NGWaJOEQa6zZ6Z12FoCjupp5YN9LgkEwJdxRK+37 KL6g== 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; bh=eHTIunh7i80u0ho1Yj2oV0/P2fSS5tsNwMZcJYurt1w=; b=H4c2mtIqDOTMNjMKfCCppMtiffi0PJeDBiV7Q4BY0CtWQKrupRLVQSUqND3kZO+lK2 v0JXl+W2M79CE6pqvWR0EZKcJVk0PITvC477zc+/VxdDImbWsUZr9yZo6fqBN9j2p64O VAZu3qveEcw2W6bW06cTnwz43P47eTaBR4dJsoBtWRYNQ8veJhSme7xHlTJ0JqpkJQVo ahleapCFkdIgKcSfk6v6s7TLGLuoaGYWDqYFzoylSBKcgLbDQyqL0lY5zqY16MCePpVe KOUXRDrZgX0br7WQBygSQ2sb6N3e7IMEewRogKytYayErPEB84pZz3ltEeKlKkdqzbvc l4Hw== X-Gm-Message-State: AOAM530azEC8o8cLD44/t3aA0cMLBM4S3fRo2Tyep0+pRlMpvniySSjo GWOAVXOKvk3IFb99Sb/JcRAqNflXT2eZE3jHCLolFh4Zquk= X-Google-Smtp-Source: ABdhPJxivfeni5Ac7k0S1JzYKYUVWo8Pqs9o5X0S4Wn2U5uhB1U98ZOdwHOXQAI6EK/nLQTS4A5d6idp3WcMiaNMcFo= X-Received: by 2002:a50:afe2:: with SMTP id h89mr12950635edd.308.1623588812836; Sun, 13 Jun 2021 05:53:32 -0700 (PDT) MIME-Version: 1.0 From: Alan Arondel Date: Sun, 13 Jun 2021 14:53:22 +0200 Message-ID: To: users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: [dpdk-users] Tx burst and ordered packets 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 Sender: "users" > >* Are you using RSS on the receiver. *> >* Packets sent in one burst should go out in order (if not it is a Intel *> >* driver bug) * > [Sidenote: its best practice to reply inline when answering questions on mailing lists.] Sorry, i'm a beginner with mailing list. No i'm not using RSS. > >* On Mon, Jun 7, 2021 at 3:09 PM Alan Arondel > wrote: *> > > >* > Hello everyone, *> >* > *> >* > I just wanted to know if a burst of packets using rte_eth_tx_burst are *> >* > send in the same order of the parameter struct rte_mbuf ** tx_pkts ? *> >* > I tried the skeleton sample which use this api and can confirm that the *> >* > received packets are not in the right order. Probably I'm doing something *> >* > wrong somewhere. * > Stephen is correct in that the rte_mbuf **tx_pkts order is the order packets > should be sent on the wire. Indeed if they are not, it is a driver bug, and should > be fixed. > Before we jump to that conclusion, can I suggest we look at how packet ordering > is being measured? Keep in mind packets could be dropped along the way, so > if we count (N) and (N+1) on the next packet, and then validate ordering by ensuring > the received packets are exactly (N, N+1), then a drop would suggest re-ordering issues... Let me explain a bit more what i am doing : I'm currently using two hosts. These two hosts are connected together without any device between them on 2 ports (10G interfaces). One of the host is generating traffic using tcpreplay with a pcap of 12 packets (basicaly http) on one interface and i have a tcpdump on the other interface. The replay is done only once so I expect to send and receive back these 12 packets. the other host is hosting the application with dpdk (skeleton sample). I changed the sample in order to wait for a burst of 6 packets. Once the burst of the 6 packets is ready, I use the rte_eth_tx_burst. I displayed the burst on terminal and also check with gdb and no issue seems to be present with the order of packets. I receive correctly the 12 packets but the order seems to be random inside of the burst which is a bit confusing (not always the same result). However, I receive correctly the first 6 packets and then the last 6 packets together. >* > I use the driver net_i40e. *>* > Dpdk version 20.11.1 *>* > Compilation without any specific parameters (meson *>* > configure/ninja/ninja install) *>* > I cannot find any discussion or information about this. * I expect that would work correctly. >* > Thank you for any reply. *>* > *>* > Regards, *>* > Alan. * Regards, -Harry