DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] Tx burst and ordered packets
@ 2021-06-13 12:53 Alan Arondel
  0 siblings, 0 replies; 5+ messages in thread
From: Alan Arondel @ 2021-06-13 12:53 UTC (permalink / raw)
  To: 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 <Alan.Arondel at enea.com <https://mails.dpdk.org/listinfo/users>> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* [dpdk-users] Tx burst and ordered packets
@ 2021-06-07 22:09 Alan Arondel
  2021-06-10  9:37 ` Alan Arondel
  2021-06-10 16:29 ` Stephen Hemminger
  0 siblings, 2 replies; 5+ messages in thread
From: Alan Arondel @ 2021-06-07 22:09 UTC (permalink / raw)
  To: users

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.

I use the driver net_i40e.
Dpdk version 20.11.1
Compilation withtout any specifique parameters (meson configure/ninja/ninja install)
I cannot find any discussion or information about this.

Thank you for any reply.

Regards,
Alan.

This message, including attachments, is CONFIDENTIAL. It may also be privileged or otherwise protected by law. If you received this email by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Enea may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. Anyone who communicates with us by email accepts these risks.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-06-13 12:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-13 12:53 [dpdk-users] Tx burst and ordered packets Alan Arondel
  -- strict thread matches above, loose matches on Subject: below --
2021-06-07 22:09 Alan Arondel
2021-06-10  9:37 ` Alan Arondel
2021-06-10 16:29 ` Stephen Hemminger
2021-06-11  9:57   ` Van Haaren, Harry

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git